JUNOS Archtecture

Embed Size (px)

Text of JUNOS Archtecture

  • 8/2/2019 JUNOS Archtecture


    White Paper

    Juniper Networks, Inc.

    1194 North Mathilda Avenue

    Sunnyvale, Caliornia 94089



    1.888 JUNIPER


    Network Operating System EvolutionJUNOS Sotware: Architectural Choices at the Foreronto Networking

    Part Number: 200264-002 Aug 2008

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.2

    Network Operating System Evolution

    Table of Contents

    Executive Summary 3

    Introduction 3

    Origin and Evolution o Network Operating Systems 3

    First-Generation OS: Monolithic Architecture 4

    Second-Generation OS: Control Plane Modularity 4Third-Generation OS: Flexibility, Scalability and Continuous Operation 5

    Basic OS Design Considerations 5

    Commercial Versus Open-Source Donor OS 6

    Functional Separation and Process Scheduling 6

    Memory Model 6

    Scheduling Discipline 6

    Virtual Memory/Preemptive Scheduling Programming Model 7

    Generic Kernel Design 8

    Monolithic Versus Microkernel Network Operating System Designs 9

    JUNOS Sotware Kernel 10

    Process Scheduling in JUNOS Sotware 11

    JUNOS Sotware Routing Protocol Process 12

    Scalability 14Scaling Down 14

    Scaling Up 15

    Architecture and Inrastructure 16

    Parallelism 16

    Flexibility and Portability 17

    Degrees o Modularity 19

    Open Architecture 19

    Product Maintenance 19

    Sel-Healing 20

    Troubleshooting 21

    Quality and Reliability 21

    System Integrity 21

    Release Process Summary 23

    Final Product Quality and Stability 24

    Conclusion 25

    What Makes JUNOS Sotware Dierent 25

    Features 25

    Predictability: JUNOS Sotware Releases 20042007 25

    About Juniper Networks 26

    List of FiguresFigure 1 Typical Preemptive Scheduling Sequence 7

    Figure 2 Resource Management Conicts in Preemptive Scheduling 7

    Figure 3 Generic JUNOS Sotware 90 Architectural Structure 10

    Figure 4 Multilevel CPU Scheduling in JUNOS Sotware 12

    Figure 5 Hierarchical Protocol Stack Operation 13

    Figure 6 Typical CPU Times Capture (rom NEC 8800 Product Documentation) 16

    Figure 7 Product Consolidation Under a Common Operating System 18

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 3

    Network Operating System Evolution

    Executive Summary

    This paper discusses the requirements and challenges inherent in the design o carrier-class

    network operating system (OS) Key acets o JUNOS sotware, the Juniper Networks OS, are used

    to illustrate the evolution o OS design and underscore the relationship between unctionality and

    architectural decisions

    The challenge o designing a contemporary network operating system is examined rom dierentangles, including exibility, ability to power a wide range o platorms, nonstop operation, and

    parallelism Architectural challenges, trade-os and opportunities are identifed, as well as some o

    the best practices in building state-o-the-art network operating systems


    Modern network devices are complex entities composed o both silicon and sotware Thus, designing

    an efcient hardware platorm is not, by itsel, sufcient to achieve an eective, cost-efcient and

    operationally tenable product The control plane plays a critical role in the development o eatures

    and in ensuring device usability

    Although progress rom the development o aster CPU boards and orwarding planes is visible,

    structural changes made in sotware are usually hidden, and while vendor collateral oten oers a list

    o eatures in a carrier-class package, operational experiences may vary considerably

    Products that have been through several generations o sotware releases provide the best examples

    o the dierence made by the choice o OS It is still not uncommon to fnd routers or switches that

    started lie under older, monolithic sotware and later migrated to more contemporary designs The

    positive eect on stability and operational efciency is easy to notice and appreciate

    However, migration rom one network operating system to another can pose challenges rom

    nonoverlapping eature sets, noncontiguous operational experiences and inconsistent sotware

    quality These potential challenges make it is very desirable to build a control plane that can power

    the hardware products and eatures supported in both current and uture markets

    Developing a exible, long-lasting and high-quality network OS provides a oundation that can

    graceully evolve to support new needs in its height or up and down scaling, width or adoptionacross many platorms, and depth or rich integration o new eatures and unctions It takes time,

    signifcant investment and in-depth expertise

    Most o the engineers writing the early releases o JUNOS sotware came rom other companies

    where they had previously built network sotware They had frsthand knowledge o what worked

    well, and what could be improved These engineers ound new ways to solve the limitations that

    theyd experienced in building the older operating systems Resulting innovations in JUNOS sotware

    are signifcant and rooted in its earliest design stages Still, to ensure that our products anticipate

    and ulfll the next generation o market requirements, JUNOS sotware is periodically reevaluated

    to determine whether any changes are needed to ensure that it continues to provide the reliability,

    perormance and resilience or which it is known

    Origin and Evolution of Network Operating Systems

    Contemporary network operating systems are mostly advanced and specialized branches o POSIX-

    compliant sotware platorms and are rarely developed rom scratch The main reason or this

    situation is the high cost o developing a world-class operating system all the way rom concept to

    fnished product By adopting a general-purpose OS architecture, network vendors can ocus on

    routing-specifc code, decrease time to market, and beneft rom years o technology and research

    that went into the design o the original (donor) products

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.4

    Network Operating System Evolution

    For example, consider Table 1, which lists some operating systems or routers and their respective

    origins (the Generation column is explained in the ollowing sections)

    Table 1. Router Operating System Origins

    Vendor Router OS Donor OS Donor OS Owner Generation Donor OS Web site





    FreeBSD Internet community 2, 3 www.reebsd.org

    Cisco IOS-XR QNX QNX Sotware


    2 www.qnx.com

    Cisco IOS n/a Proprietary 1 n/a

    Cisco IOS-XE IOS, Linux Hybrid (ASR) 1.5 n/a

    Cisco Modular IOS IOS, QNX Hybrid (6500) 1.5 n/a



    SR OS VxWorks WindRiver 2 www.windriver.com

    Redback SEOS NetBSD Internet community 2 www.netbsd.org

    Force10 FTOS NetBSD Internet community 2 www.netbsd.org

    Extreme ExtremeWARE Linux Internet community 2 www.xoslinux.org

    Generally speaking, network operating systems in routers can be traced to three generations odevelopment, each with distinctively dierent architectural and design goals

    First-Generation OS: Monolithic Architecture

    Typically, frst-generation network operating systems or routers and switches were proprietary

    images running in a at memory space, oten directly rom ash memory or ROM While supporting

    multiple processes or protocols, packet handling and management, they operated using a

    cooperative, multitasking model in which each process would run to completion or until it voluntarily

    relinquished the CPU

    All frst-generation network operating systems shared one trait: They eliminated the risks o running

    ull-size commercial operating systems on embedded hardware Memory management, protection

    and context switching were either rudimentary or nonexistent, with the primary goals being a small

    ootprint and speed o operation Nevertheless, frst-generation network operating systems madenetworking commercially viable and were deployed on a wide range o products The downside was

    that these systems were plagued with a host o problems associated with resource management

    and ault isolation; a single runaway process could easily consume the processor or cause the entire

    system to ail Such ailures were not uncommon in the data networks controlled by older sotware

    and could be triggered by sotware errors, rogue trafc and operator errors

    Legacy platorms o the frst generation are still seen in networks worldwide, although they are

    gradually being pushed into the lowest end o the telecom product lines

    Second-Generation OS: Control Plane Modularity

    The mid-1990s were marked by a signifcant increase in the use o data networks worldwide, which

    quickly challenged the capacity o existing networks and routers By this time, it had become evident

    that embedded platorms could run ull-size commercial operating systems, at least on high-endhardware, but with one catch: They could not sustain packet orwarding with satisactory data rates

    A breakthrough solution was needed It came in the concept o a hard separation between the control

    and orwarding planean approach that became widely accepted ater the success o the industrys

    frst application-specifc integrated circuit (ASIC)-driven routing platorm, the Juniper Networks M40

    Forwarding packets entirely in silicon was proven to be viable, clearing the path or next-generation

    network operating systems, led by Juniper with its JUNOS sotware

    Today, the original M40 routers are mostly retired, but their legacy lives in many similar designs, and

    their blueprints are widely recognized in the industry as the second-generation reerence architecture

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 5

    Network Operating System Evolution

    Second-generation network operating systems are ree rom packet switching and thus are ocused

    on control plane unctions Unlike its frst-generation counterparts, a second-generation OS can ully

    use the potential o multitasking, multithreading, memory management and context manipulation,

    all making systemwide ailures less common Most core and edge routers installed in the past ew

    years are running second-generation operating systems, and it is these systems that are currently

    responsible or moving the bulk o trafc on the Internet and in corporate networks

    However, the lack o a sotware data plane in second-generation operating systems prevents

    them rom powering low-end devices without a separate (hardware) orwarding plane Also, some

    customers cannot migrate rom their older sotware easily because o compatibility issues and legacy

    eatures still in use

    These restrictions led to the rise o transitional (generation 15) OS designs, in which a frst-

    generation monolithic image would run as a process on top o the second-generation scheduler and

    kernel, thus bridging legacy eatures with newer sotware concepts The idea behind generation

    15 was to introduce some headroom and gradually move the unctionality into the new code, while

    retaining eature parity with the original code base Although interesting engineering exercises, such

    designs were not as eature-rich as their predecessors, nor as eective as their successors, making

    them o questionable value in the long term

    Third-Generation OS: Flexibility, Scalability and Continuous OperationAlthough second-generation designs were very successul, the past 10 years have brought new

    challenges Increased competition led to the need to lower operating expenses and a coherent case

    or network sotware exible enough to be redeployed in network devices across the larger part o the

    end-to-end packet path From multiple-terabit routers to Layer 2 switches and security appliances, the

    best-in-class catchphrase can no longer justiy a splintered operational experiencetrue network

    operating systems are clearly needed Such systems must also achieve continuous operation, so

    that sotware ailures in the routing code, as well as system upgrades, do not aect the state o the

    network Meeting this challenge requires availability and convergence characteristics that go ar

    beyond the hardware redundancy available in second-generation routers

    Another key goal o third-generation operating systems is the capability to run with zero downtime

    (planned and unplanned) Drawing on the lesson learned rom previous designs regarding the

    difculty o moving rom one OS to another, third-generation operating systems also should makethe migration path completely transparent to customers They must oer an evolutionary, rather than

    revolutionary, upgrade experience typical to the retirement process o legacy sotware designs

    Basic OS Design Considerations

    Choosing the right oundation (prototype) or an operating system is very important, as it has

    signifcant implications or the overall sotware design process and fnal product quality and

    serviceability This importance is why OEM vendors sometimes migrate rom one prototype platorm

    to another midway through the development process, seeking a better ft Generally, the most

    common transitions are rom a proprietary to a commercial code base and rom a commercial code

    base to an open-source sotware oundation

    Regardless o the initial choice, as networking vendors develop their own code, they get urther and

    urther away rom the original port, not only in protocol-specifc applications but also in the system

    area Extensions such as control plane redundancy, in-service sotware upgrades and multichassis

    operation require signifcant changes on all levels o the original design However, it is highly desirable

    to continue borrowing content rom the donor OS in areas that are not normally the primary ocus

    o networking vendors, such as improvements in memory management, scheduling, multicore and

    symmetric multiprocessing (SMP) support, and host hardware drivers With proper engineering

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.6

    Network Operating System Evolution

    discipline in place, the more active and peer-reviewed the donor OS is, the more quickly related

    network products can beneft rom new code and technology

    This relationship generally explains another market trend evident in Table 1only two out o fve

    network operating systems that emerged in the routing markets over the past 10 years used a

    commercial OS as a oundation

    Junipers main operating system, JUNOS sotware, is an excellent illustration o this industrytrend The basis o the JUNOS sotware kernel comes rom the FreeBSD UNIX OS, an open-source

    sotware system The JUNOS sotware kernel and inrastructure have since been heavily modifed to

    accommodate advanced and unique eatures such as state replication, nonstop active routing and

    in-service sotware upgrades, all o which do not exist in the donor operating system Nevertheless,

    the JUNOS sotware tree can still be synchronized with the FreeBSD repository to pick the latest in

    system code, device drivers and development tool chains, which allows Juniper Networks engineers to

    concentrate on network-specifc development

    Commercial Versus Open-Source Donor OS

    The advantage o a more active and popular donor OS is not limited to just minor improvements

    the cutting edge o technology creates new dimensions o product exibility and usability Not being

    locked into a single-vendor ramework and roadmap enables greater control o product evolution as

    well as the potential to gain rom progress made by independent developers

    This beneft is evident in JUNOS sotware, which became a frst commercial product to oer hard

    resource separation o the control plane and a real-time sotware data plane Juniper-specifc

    extension o the original BSD system architecture relies on multicore CPUs and makes JUNOS

    sotware the only operating system that powers both low-end sotware-only systems and high-end

    multiple-terabit hardware platorms with images built rom the same code tree This technology and

    experience could not be created without support rom the entire Internet-driven community The

    powerul collaboration between leading individuals, universities and commercial organizations helps

    JUNOS sotware stay on the very edge o operating system development Further, this collaboration

    works both ways: Juniper donates to the ree sotware movement, one example being the Juniper

    Networks FreeBSD/MIPS port

    Functional Separation and Process SchedulingMultiprocessing, unctional separation and scheduling are undamental or almost any sotwaredesign, including network sotware Because CPU and memory are shared resources, all running

    threads and processes have to access them in a serial and controlled ashion Many design choices

    are available to achieve this goal, but the two most important are the memory model and the

    scheduling discipline The next section briey explains the intricate relation between memory, CPU

    cycles, system perormance and stability

    Memory Model

    The memory model defnes whether processes (threads) run in a common memory space I they do,

    the overhead or switching the threads is minimal, and the code in dierent threads can share data

    via direct memory pointers The downside is that a runaway process can cause damage in memory

    that does not belong to it

    In a more complex memory model, threads can run in their own virtual machines, and the

    operating system switches the context every time the next thread needs to run Because o this

    context switching, direct communication between threads is no longer possible and requires special

    interprocess communication (IPC) structures such as pipes, fles and shared memory pools

    Scheduling Discipline

    Scheduling choices are primarily between cooperative and preemptive models, which defne whether

    thread switching happens voluntarily (Figure 1) A cooperative multitasking model allows the thread

    to run to completion, and a preemptive design ensures that every thread gets access to the CPU

    regardless o the state o other threads

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 7

    Network Operating System Evolution

    Figure 1. Typical Preemptive Scheduling Sequence

    Virtual Memory/Preemptive Scheduling Programming Model

    Virtual memory with preemptive scheduling is a great design choice or properly constructed

    unctional blocks, where interaction between dierent modules is limited and well defned This

    technique is one o the main benefts o the second-generation OS designs and underpins the stability

    and robustness o contemporary network operating systems However, it has its own drawbacks

    Notwithstanding the overhead associated with context switching, consider the interaction between

    two threads (Figure 2), A and B, both relying on the common resource R Because threads do not

    detect their relative scheduling in the preemptive model, they can actually access R in a dierent

    order and with varying intensity For example, R can be accessed by A, then B, then A, then A and

    then B again I thread B modifes resource R, thread A may get dierent results at dierent times

    and without any predictability For instance, i R is an interior gateway protocol (IGP) next hop, B is anIGP process, and A is a BGP process, then BGP route installation may ail because the underlying next

    hop was modifed midway through routing table modifcation This scenario would never happen

    in the cooperative multitasking model, because the IGP process would release the CPU only ater it

    fnishes the next-hop maintenance

    Figure 2. Resource Management Conficts in Preemptive Scheduling

    Thread BThread A

    Interrupt suspends thread A

    Thread A is selected for run

    Thread B preempts thread A

    Thread A resumes

    System idle, threads A and B ready to run

    Thread AThread B

    Resource R read by thread B

    Resource R read by thread A Threads A view on Resource R is inconsistent

    Thread B modies resource R

    Thread A works on the resource R assuming it is current

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.8

    Network Operating System Evolution

    This problem is well researched and understood within sotware design theory, and special solutions

    such as resource locks and synchronization primitives are easily available in nearly every operating

    system However, the eectiveness o IPC depends greatly on the number o interactions between

    dierent processes As the number o interacting processes increases, so does the number o IPC

    operations In a careully designed system, the number o IPC operations is proportional to the number

    o processes (N) In a system with extensive IPC activity, this number can be proportional to N2

    Exponential growth o an IPC map is a negative trend not only because o the associated overhead,

    but because o the increasing number o unexpected process interactions that may escape the

    attention o sotware engineers

    In practice, overgrown IPC maps result in systemwide IPC meltdowns when major events trigger

    intensive interactions For instance, pulling a line card would normally aect interace management,

    IGP, exterior gateway protocol and trafc engineering processes, among others When interprocess

    interactions are not well contained, this event may result in locks and tight loops, with multiple

    threads waiting on each other and vital system operations such as routing table maintenance and IGP

    computations temporarily suspended Such deects are signatures o improper modularization, where

    similar or heavily interacting unctional parts do not run as one process or one thread

    The right question to ask is, Can a system be too modular? The conventional wisdom says, Yes

    Excessive modularity can bring long-term problems, with code complexity, mutual locks andunnecessary process interdependencies Although none o these may be severe enough to halt

    development, eature velocity and scaling parameters can be aected Complex process interactions

    make programming or such a network OS an increasingly difcult task

    On the other hand, the cooperative multitasking, shared memory paradigm becomes clearly

    suboptimal i unrelated processes are inuencing each other via the shared memory pool and

    collective restartability A classic problem o frst-generation operating systems was systemwide

    ailure due to a minor bug in a nonvital process such as SNMP or network statistics Should such an

    error occur in a protected and independently restartable section o system code, the deect could

    easily be contained within its respective code section

    This brings us to an important conclusion

    No fxed principle in sotware design fts all possible situations

    Ideally, code design should ollow the most efcient paradigm and apply dierent strategies in

    dierent parts o the network OS to achieve the best marriage o architecture and unction This

    approach is evident in JUNOS sotware, where unctional separation is maintained so that cooperative

    multitasking and preemptive scheduling can both be used eectively, depending on the degree o IPC

    containment between unctional modules

    Generic Kernel Design

    Kernels normally do not provide any immediately perceived or revenue-generating unctionality

    Instead, they perorm housekeeping activities such as memory allocation and hardware management

    and other system-level tasks Kernel threads are likely the most oten run tasks in the entire system

    Consequently, they have to be robust and run with minimal impact on other processes

    In the past, kernel architecture largely defned the operating structure o the entire system with

    respect to memory management and process scheduling Hence, kernels were considered important

    dierentiators among competing designs

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 9

    Network Operating System Evolution

    Historically, the disputes between the proponents and opponents o lightweight versus complex kernel

    architectures came to a practical end when most operating systems became unctionally decoupled

    rom their respective kernels Once sotware distributions became available with alternate kernel

    confgurations, researchers and commercial developers were ree to experiment with dierent designs

    For example, the original Carnegie-Mellon Mach microkernel was originally intended to be a

    drop-in replacement or the kernel in BSD UNIX and was later used in various operating systems,

    including mkLinux and GNU FSF projects Similarly, some sotware projects that started lie as purely

    microkernel-based systems later adopted portions o monolithic designs

    Over time, the radical approach o having a small kernel and moving system unctions into the

    user-space processes did not prevail A key reason or this was the overhead associated with extra

    context switches between requently executed system tasks running in separate memory spaces

    Furthermore, the benefts associated with restartability o essentially all system processes proved to

    be o limited value, especially in embedded systems With the system code being very well tested

    and limited to scheduling, memory management and a handul o device drivers, the potential errors

    in kernel subsystems are more likely to be related to hardware ailures than to sotware bugs This

    means, or example, that simply restarting a aulty disk driver is unlikely to help the routing engine

    stay up and running, as the problem with storage is likely related to a hardware ailure (or example,

    uncorrectable ault in a mass storage device or system memory bank)

    Another interesting point is that although both monolithic and lightweight kernels were widely

    studied by almost all operating system vendors, ew have settled on purist implementations

    For example, Apples Mac OS X was originally based on microkernel architecture, but now runs

    system processes, drivers and the operating environment in BSD-like subsystems Microsot NT

    and derivative operating systems also went through multiple changes, moving critical perormance

    components such as graphical and I/O subsystems in and out o the system kernel to fnd the right

    balance o stability, perormance and predictability These changes make NT a hybrid operating

    system On the other hand, reeware development communities such as FSF, FreeBSD and NetBSD

    have mostly adopted monolithic designs (or example, Linux kernel) and have gradually introduced

    modularity into selected kernel sections (or example, device drivers)

    So what dierence does kernel architecture make to routing and control?

    Monolithic Versus Microkernel Network Operating System Designs

    In the network world, both monolithic and microkernel designs can be used with success

    However, the ever-growing requirements or a system kernel quickly turn any classic implementation

    into a compromise Most notably, the capability to support a real-time orwarding plane along with

    stateul and stateless orwarding models and extensive state replication requires a mix o eatures not

    available rom any existing monolithic or microkernel OS implementation

    This lack can be overcome in two ways

    First, a network OS can be constrained to a limited class o products by design For instance, i the

    OS is not intended or mid- to low-level routing platorms, some requirements can be lited The same

    can be done or ow-based orwarding devices, such as security appliances This artifcial restriction

    allows the network operating systems to stay closer to their general-purpose siblingsat the cost oracturing the product lineup Dierent network element classes will now have to maintain their own

    operating systems, along with unique code bases and protocol stacks, which may negatively aect

    code maturity and customer experience

    Second, the network OS can evolve into a specialized design that combines the architecture and

    advantages o multiple classic implementations

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.10

    Network Operating System Evolution

    This custom kernel architecture is a more ambitious development goal because the network OS gets

    urther away rom the donor OS, but the end result can oer the benefts o eature consistency, code

    maturity, and operating experience This is the design path that Juniper selected or JUNOS sotware

    JUNOS Software Kernel

    According to the ormal criteria, the JUNOS sotware kernel is ully customizable (Figure 3) At the

    very top is a portion o code that can be considered a microkernel It is responsible or real-time

    packet operations and memory management, as well as interrupts and CPU resources One level

    below it is a more conventional kernel that contains a scheduler, memory manager and device

    drivers in a package that looks more like a monolithic design Finally, there are user-level (POSIX)

    processes that actually serve the kernel and implement unctions normally residing inside the kernels

    o classic monolithic router operating systems Some o these processes can be compound or run on

    external CPUs (or packet orwarding engines) In JUNOS sotware, examples include periodic hello

    management, kernel state replication and protected system domains (PSDs)

    The entire structure is strictly hierarchical, with no underlying layers dependent on the operations

    o the top layers This high degree o virtualization allows the JUNOS sotware kernel to be both ast

    and exible

    However, even the most advanced kernel structure is not a revenue-generating asset o the network

    element Uptime is the only measurable metric o system stability and quality This is why the

    undamental dierence between the JUNOS sotware kernel and competing designs lies in the ocus

    on reliability

    Figure 3. Generic JUNOS Sotware 9.0 Architectural Structure

    RT Core

    BSD KernelReal-time domain

    PFE kernelOtherreal-timethreads


















    Non real-time domain

    Real-time domain

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 11

    Network Operating System Evolution

    Coupled with Junipers industry-leading nonstop active routing and system upgrade implementation,

    kernel state replication acts as the cornerstone or continuous operation In act, the JUNOS sotware

    redundancy scheme is designed to protect data plane stability and routing protocol adjacencies at the

    same time With in-service sotware upgrade, networks powered by JUNOS sotware are becoming

    immune to the downtime related to the introduction o new eatures or bug fxes, enabling them to

    approach true continuous operation Continuous operation demands that the integrity o the control

    and orwarding planes remains intact in the event o ailover or system upgrades, including minorand major release changes Devices running JUNOS sotware will not miss or delay any routing

    updates when either a ailure or a planned upgrade event occurs

    This goal o continuous operation under all circumstances and during maintenance tasks is ambitious,

    and it reects Junipers innovation and network expertise, which is unique among network vendors

    Process Scheduling in JUNOS Sotware

    Innovation in JUNOS sotware does not stop at the kernel level; rather, it extends to all aspects o

    system operation

    As mentioned beore, there are two tiers o schedulers in JUNOS sotware, the topmost becoming active

    in systems with a sotware data plane to ensure the real-time handling o incoming packets It operates

    in real time and ensures that quality o service (QoS) requirements are met in the orwarding path

    The second-tier (non-real-time) scheduler resides in the base JUNOS sotware kernel and is similar

    to its FreeBSD counterpart It is responsible or scheduling system and user processes in a system to

    enable preemptive multitasking

    In addition, a third-tier scheduler exists within some multithreaded user-level processes, where

    threads operate in a cooperative, multitasking model When a compound process gets the CPU share,

    it may treat it like a virtual CPU, with threads taking and leaving the processor according to their

    execution ow and the sequence o atomic operations This approach allows closely coupled threads

    to run in a cooperatively multitasking environment and avoid being entangled in extensive IPC and

    resource- locking activities (Figure 4)

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.12

    Network Operating System Evolution

    Figure 4. Multilevel CPU Scheduling in JUNOS Sotware

    Another interesting aspect o multi-tiered scheduling is resource separation Unlike frst-generation

    designs, JUNOS sotware systems with a sotware orwarding plane cannot reeze when overloaded

    with data packets, as the frst-level scheduler will continue granting CPU cycles to the control plane

    JUNOS Software Routing Protocol Process

    The routing protocol process daemon (RPD) is the most complex process in a JUNOS sotware

    system It not only contains much o the actual code or routing protocols, but also has its own

    scheduler and memory manager The scheduler within RPD implements a cooperative multitaskingmodel, in which each thread is responsible or releasing the CPU ater an atomic operation has been

    completed This design allows several closely related threads to coexist without the overhead o IPC

    and to scale without risk o unwanted interactions and mutual locks

    The threads within RPD are highly modular and may also run externally as standalone POSIX

    processesthis is, or example, how many periodic protocol operations are perormed In the early

    days o RPD, each protocol was responsible or its own adjacency management and control Now,

    most keepalive processing resides outside RPD, in the Bidirectional Forwarding Detection protocol

    (BFD) daemon and periodic packet management process daemon (PPMD), which are, in turn,

    Real-time microkernelScheduling Level I

    Scheduling Level II

    Real-time Non-real-time

    Forwarding code Kernel








    Thread Thread Thread

    Scheduling Level III

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 13

    Network Operating System Evolution

    distributed between the routing engine and the line cards The unique capability o RPD to combine

    preemptive and cooperative multitasking powers the most scalable routing stack in the market

    Compound processes similar to RPD are known to be very eective but sometimes are criticized or

    the lack o protection between components It has been said that a ailing thread will cause the entire

    protocol stack to restart Although this is a valid point, it is easy to compare the impact o this error

    against the perormance o the alternative structure, where every routing protocol runs in a dedicated

    memory space

    Assume that the router serves business VPN customers, and the ultimate revenue-generating product

    is continuous reachability between remote sites At the very top is a BGP process responsible or

    creating orwarding table entries Those entries are ultimately programmed into a packet path ASIC or

    the actual header lookup and orwarding I the BGP process hits a bug and restarts, orwarding table

    entries may become stale and would have to be ushed, thus disrupting customer trafc But BGP

    relies on lower protocols in the stack or trafc engineering and topology inormation, and it will not

    be able to create the orwarding table without OSPF or RSVP I any o these processes are restarted,

    BGP will also be aected (Figure 5) This case supports the benefts o running BGP, OSPF and RSVP in

    shared memory space, where the protocols can access common data without IPC overhead

    Figure 5. Hierarchical Protocol Stack Operation

    In a reverse example, several routing protocols legitimately operate at the same level and do not

    depend on each other One case would be unicast amily BGP and Protocol Independent Multicast

    (PIM) Although both depend on reachability inormation about connected and IGP known networks,

    ailures in one protocol can be saely ignored in the other For instance, unicast orwarding to remote

    BGP known networks can continue even i multicast orwarding is disrupted by PIM ailure In this

    case, the multicast and unicast portions o the routing code are better o stored in dierent protected

    domains so they do not aect each other















  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.14

    Network Operating System Evolution

    Looking deeper into the realm o exceptions, we fnd that they occur due to sotware and hardware

    ailures alike A aulty memory bank may yield the same eect as sotware that reerences a corrupt

    pointerin both cases, the process will most likely be restarted by a system

    In general, the challenge in ensuring continuous operation is ourold:

    First, the existing orwarding entries should not be aected Restart o a process should not

    aect the trafc owing through the router

    Second, the existing orwarding entries should not become stale Routers should not misdirect

    trafc in the event o a topology change (or lack thereo)

    Third, protocol operation should have low overhead and be well contained Excessive CPU

    utilization and deadlocks are not allowed as they negatively aect node stability

    Fourth, the routing protocol peers should not be aected The network should remain stable

    Once again, we see that ew sotware challenges can be met by structuring in one specifc way

    Routing threads may operate using a cooperative, preemptive or hybrid task model, but ailure

    recovery still calls or state restoration using external checkpoint acilities I vital routing inormation

    were duplicated elsewhere and could be recovered promptly, the ailure would be transparent to

    user trafc and protocol peers alike Transparency through prompt recovery is the principal concept

    underlying any NSR design and the main idea behind the contemporary Juniper Networks RPDimplementation

    Instead o ocusing on one technology or structure, Juniper Networks engineers evolve the JUNOS

    sotware protocol stack according to a survival o the fttest principle, toward the goal o true

    nonstop operation, reliability and usability State replication, checkpointing and IPC are all used to

    reduce the impact o sotware and hardware ailures The JUNOS sotware control plane is designed to

    maintain speed, uptime and ull state under the most unavorable network situations

    Adapting to ever-changing real-world conditions and practical applications, the JUNOS sotware

    routing architecture will continue to evolve to become even more advanced, with threads added

    or removed as dictated by the needs o best-in-class sotware design Juniper Networks sotware is

    constantly adapted to the operating environment, and as you read this paragraph, new ideas and

    concepts are being integrated into JUNOS sotware Stay tuned


    JUNOS sotware can scale up and down to platorms o dierent sizes This capability is paramount to

    the concept o network OS that can power a diverse range o network elements The next section

    highlights the challenges and opportunities seen in this aspect o networking

    Scaling Down

    Scaling down is the capacity o a network operating system to run on low-end hardware, thus creating

    a consistent user experience and ensuring the same level o equipment resilience and reliability

    across the entire network, rom high-end to low-end routing platorms

    Achieving this goal involves multiple challenges or a system designer Not only does the code have

    to be efcient on dierent hardware architectures, but low-end systems bring their own unique

    requirements, such as resource constraints, cost, and unique security and operations models In

    addition, many low-end routers, frewalls and switches require at least some CPU assistance or

    packet orwarding or services, thus creating the need or a sotware orwarding path

    Taking an arbitrary second-generation router OS and executing it in a low-end system can be a

    challenging task, evidenced by the act that no vendor except Juniper actually ships low-end and high-

    end systems running the same OS based on second-generation design principles or better

    But bringing a carrier-sized OS all the way down to the enterprise is also rewarding

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 15

    Network Operating System Evolution

    It brings immediate advantages to customers in the orm o uniorm management, compatibility and

    OPEX savings across the entire network It also improves the original OS design During the asting

    exercise needed to ft the OS into low-end devices, the code is extensively reviewed, and code

    structure is optimized Noncritical portions o code are removed or redesigned

    Whats more, the unique requirements o variable markets (or example, security, Ethernet and

    enterprise) help stress-test the sotware in a wide range o situations, thus hardening the overall

    design Scaling limits are pushed across many boundaries when the sotware adopts new roles and


    Finally, low-end systems typically ship in much larger quantities than high-end systems The

    increased number o systems in the feld proportionally amplifes the chances o fnding nonobvious

    bugs and decreases the average impact o a given bug on the installed base worldwide 1 All these

    actors together translate into a better product, or both carriers and enterprises

    It can be rightully said that the requirement or scaling down has been a major source o inspiration

    or JUNOS sotware developers since introduction o the Juniper Networks J-series The quest or

    efcient inrastructure has helped with such innovative projects as JUNOS Sotware SDK, and

    ultimately paved the way to the concept o one OS powering the entire networkthe task that has

    never been achieved in history o networking beore

    Scaling Up

    Empowerment o a multichassis, multiple-terabit router is associated with words such as upscale and

    high end, all o which apply to JUNOS sotware However, it is mostly the control plane capacity that

    challenges the limits o sotware in modern routers with all-silicon orwarding planes For example,

    a 16-terabit router with 80 x 10 Gigabit Ethernet core-acing interaces may place less stress on its

    control plane than a 320-megabit router with 8,000 slow-speed links and a large number o IGP and

    BGP adjacencies behind them

    Scaling is dependent on many actors One o the most important is proper level o modularity

    As discussed in the previous sections, poor containment o intermodule interactions can cause

    exponential growth in supplementary operations and bring a system to gridlock

    Another actor is design goal and associated architectural decisions and degree o complexity For

    instance, i a router was never intended to support 5,000 MPLS LSP circuits, this number may still beconfgurable, but will not operate reliably and predictably The inrastructure changes required to fx

    this issue can be quite signifcant

    Realistic, multidimensional scaling is an equivalent o the Dhrystone2 benchmark This scaling is

    how a routing system proves itsel to be commercially attractive to customers Whenever discussing

    scaling, it is always good to ask vendors to stand behind their announced scaling limits For example,

    the capability to confgure 100,000 logical interaces on a router does not necessarily mean that such

    a confguration is viable, as issues may arise on dierent rontsslow responses to user commands,

    sotware timeouts and protocol adjacency loss Vendor commitment means that the advertised

    limits are routinely checked and tested and new eature development occurs according to relevant


    Scaling is where JUNOS sotware delivers

    Some o the biggest networks in the world are built around JUNOS sotware scaling capacities,

    supporting thousands o BGP and IGP peers on the same device Likewise, core routers powered by

    JUNOS sotware can support tens o thousands o transit MPLS label-switched paths (LSPs) With its

    industry-leading slot density on the Juniper Networks T-series platorm, JUNOS sotware has proven to

    be one o the most scalable network operating systems in existence

    1This statement assumes a good systems test methodology, where toxic deects are never shipped to customers and chances or the widely experienced sotware problems

    are relatively small2A short synthetic benchmark program by Reinhold Weicker, intended to be representative o system (integer) programming

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.16

    Network Operating System Evolution

    Architecture and Infrastructure

    This section addresses architecture and inrastructure concerns related to parallelism, exibility and

    portability, and open architecture


    Advances in multicore CPU development and the capability to run several routing processors in asystem constitute the basis or increased efciency in a router control plane However, fnding the

    right balance o price and perormance can also be very difcult

    Unlike the data mining and computational tasks o supercomputers, processing o network updates is

    not a static job A block o topology changes cannot be prescheduled and then sliced across multiple

    CPUs In routers and switches, network state changes asynchronously (as events happen), thus

    rendering time-based load sharing irrelevant

    Sometimes vendors try to solve this dilemma by statically sharing the load in unctional, rather

    than temporal, domains In other words, they claim that i the router OS can use separate routing

    processors or dierent tasks (or example, OSPF or BGP), it can also distribute the bulk o data

    processing across multiple CPUs

    To understand whether this is a valid assumption, lets consider a typical CPU utilization capture(Figure 6) What is interesting here is that the dierent processes are not computationally active

    at the same timeOSPF and BGP do not compete or CPU cycles Unless the router runs multiple

    same-level protocols simultaneously, the well-designed network protocol stack stays airly orthogonal

    Dierent protocols serve dierent needs and seldom converge at the same time

    >show processes cpu seconds unicastDate Average RIP OSPF BGP RIPng OSPF6 BGP4+ RA ISIS01/22 15:48:19 3 0 0 0 0 0 0 0 001:22 15:48:20 3 0 1 0 0 0 0 0 001/22 15:49:18 3 0 0 1 0 0 0 0 0

    Figure 6. Typical CPU Times Capture (rom NEC 8800 Product Documentation)

    For instance, an IGP topology change may trigger a Dijkstra algorithm computation; until it is

    complete, BGP next-hop updates do not make much sense At the same time, all protected MPLS LSPs

    should all on precomputed alternate paths and not cause major RSVP activities

    Thus, the gain rom placing dierent processes o a single control plane onto physically separate

    CPUs may be limited, while the loss rom the overhead unctions such as synchronization and

    distributed memory unifcation may be signifcant

    Does this mean that the concept o parallelism is not applicable to the routing processors? Not at all

    Good coding practice and modern compilers can make excellent use o multicore and SMP

    hardware, while clustered routing engines are indispensable when building multichassis (single

    control and data plane spanning multiple chassis) or segmented (multiple control and data planes

    within a single physical chassis) network devices Furthermore, high-end designs may allow or

    independent scaling o control and orwarding planes, as implemented in the highly acclaimed

    Juniper Networks JCS 1200 system

    With immediate access to state-o-the art processor technology, Juniper Networks engineers

    heavily employ parallelism in the JUNOS sotware control plane design, targeting both elegance

    and unctionality

    A unctional solution is the one that speeds up the control plane without unwanted side eects

    such as limitations in orwarding capacity When deployed in a JCS 1200 system, JUNOS sotware

    can power multiple control plane instances (system domains) at the same time without consuming

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 17

    Network Operating System Evolution

    revenue-generating slots in the router chassis Moreover, the JUNOS sotware architecture can run

    multiple routing systems (including third-party code) rom a single rack o routing engines, allowing an

    arbitrary mix-and-match o control plane and data plane resources within a point o presence (POP)

    These unique capabilities translate into immediate CAPEX savings, because a massively parallel control

    plane can be built independent o the orwarding plane and will never conront a limited common

    resource (such as the number o physical routers or a number o slots in each chassis)

    Elegance means the design should also bring other technical advantages: or instance, bypassing

    space and power requirements associated with the embedded chassis and thus enabling use o aster

    silicon and speeding up the control plane Higher CPU speed and memory limits can substantially

    improve the convergence and scaling characteristics o the entire routing domain

    The goal o Juniper design philosophy is tangible benefts to our customerswithout cutting corners

    Flexibility and Portability

    A sign o a good OS design is the capability to adapt the common sotware platorm to various needs

    In the network world, this equates to the adoption o new hardware and markets under the same

    operating system

    The capability to extend the common operating system over several products brings the ollowing

    important benefts to customers:

    Reduced OPEX rom consistent UI experience and common management interace

    Same code or all protocols; no unique deects and interoperability issues

    Common schedule or sotware releases; a unifed eature set in the control plane

    Accelerated technology introduction; once developed, the eature ships on many platorms

    Technology companies are in constant search o innovation both internally and externally New

    network products can be developed in-house or within partnerships or acquired Ideally, a modern

    network OS should be able to absorb domestic (internal) hardware platorms as well as oreign

    (acquired) products, with the latter being gradually olded into the mainstream sotware line (Figure 7)

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.18

    Network Operating System Evolution

    Figure 7. Product Consolidation Under a Common Operating System

    The capability to absorb in-house and oreign innovations in this way is a unction o both

    sotware engineering discipline and a exible, well-designed OS that can be adapted to a wide

    range o applications

    On the contrary, the continuous emergence o internally developed platorms rom the samevendor eaturing dierent sotware trains and versions can signiy the lack o a exible and stable

    sotware oundation

    For example, when the same company develops a core router with one OS, an Ethernet switch with

    another, and a data center switch with a third, this likely means that in-house R&D groups considered

    and rejected readily available OS designs as impractical or unft Although partial integration may

    still exist through a unifed Command Line Interace (CLI) and shared code and eatures, the main

    message is that the existing sotware designs were not exible enough to be easily adapted to new

    markets and possibilities As a result, customers end up with a ractured sotware lineup, having to

    learn and maintain loosely related or completely unrelated sotware trains and develop expertise in

    all o theman operationally suboptimal approach

    In contrast to this trend, Juniper has never used a multitrain approach with JUNOS sotware and

    never initiated multiple operating system projects Since its inception in 1996, JUNOS sotware hasbeen successully ported to a number o Intel, MIPS and PowerPC architectures and currently powers

    a broad spectrum o routing products ranging rom the worlds astest T1600 routers to low-end

    routing devices, Ethernet switches and security appliances Junipers clear goal is to keep all products

    (both internally developed and acquired together with industry-leading companies and talent) under

    the same JUNOS sotware umbrella

    New platform


    New product


    Platforms A, B

    Platforms A, B,

    C, Y, Z

    Platforms A, B, C

    New company


    Platforms Y, Z

    Main software train Third-party software train

    Third-party software train

    Platform YRelease M

    Release X+1

    Release X

    Release X+N

    Release N

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 19

    Network Operating System Evolution

    Degrees o Modularity

    Sotware modularity, as previously described, has ocused on the case where tasks are split into

    multiple loosely coupled modules This type o modularity is called horizontal, as it aims at limiting

    dependency and mutual impact between processes operating at the same peer level Another

    interesting degree o modularity is known as vertical modularity, where modular layers are defned

    between parts o the operating system in the vertical direction

    Without vertical modularity, a network OS remains built or a specifc hardware and services

    layout When porting to a new target, much o this inrastructure has to be rewritten For example,

    both sotware- and hardware-based routers can provide a stateul frewall service, but they require

    dramatically dierent implementations Without a proper vertical modularity in place, these service

    implementations will not have much in common, which will ultimately translate into an inconsistent

    user experience

    Vertical modularity solves this problem, because most OS unctions become abstracted rom lower-

    level architecture and hardware capabilities Interaction between upper and lower OS levels happens

    via well-known subroutine calls Although vertical modularity itsel is almost invisible to the end user,

    it eliminates much o the inconsistency between various OS implementations This can be readily

    appreciated by NOC personnel who no longer deal with platorm-specifc singularities and code

    deects Vertical modularity is an ongoing project, and the JUNOS sotware team has always been

    very innovative in this area

    Open Architecture

    An interesting implication o vertical modularity is the capability to structure code well enough to

    document appropriate sotware interaces and allow external pluggable code While a high degree

    o modularity within a system allows easy porting to dierent and diverse hardware architectures, a

    well-defned and documented application programming interace (API) can be made available to third

    parties or development o their own applications

    In JUNOS sotware, the high degree o modularity and documentation eventually took the orm o

    the Partner Solution Development Platorm (PSDP), which opened the API and tool chain specifc

    to Juniper to customers and integrators worldwide PSDP allows these customers and integrators to

    co-design the operating system, ftting it precisely to their needs, especially in support o advanced

    and confdential applications The degree o development may vary rom minor changes to sotware

    appearance to ull-scale custom packet processing tailored to specifc needs

    The Juniper Networks Sotware Developers Kit (SDK) highlights the achievements o JUNOS

    sotware in network code design and engineering and reects the innovation that is integral to

    Junipers corporate culture This high level o synergy between original equipment manuacturer

    (OEM) vendors and operators promises to enable creation o new services and competitive business

    dierentiators, thus removing the barriers to network transormation Just as the open-source

    FreeBSD was the donor OS or JUNOS sotware, with the Juniper Networks SDK, JUNOS sotware is

    now a platorm open to all independent developers

    Product MaintenanceAnother important characteristic o products is maintainability It covers the process o dealing with

    sotware deects and new eatures, abilities to improve existing code, and the introduction o new

    services and capabilities It also makes a big dierence in the number and quality o NOC personnel

    that is required to run a network Maintainability is where a large portion o OPEX resides

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.20

    Network Operating System Evolution


    Routers are complex devices that depend on thousands o electronic components and millions o

    code lines to operate This is why some portion o the router installed base will almost inevitably

    experience sotware or hardware deects over the product lie span

    So ar, we have been describing the recovery process, in which state replication and process restarts

    are the basis o continuous operation In most cases, JUNOS sotware will recover so efciently thatcustomers never notice the problem, unless they closely monitor the system logs A ailing process may

    restart instantly with all the correct state inormation, and the router operation will not be aected

    But even the best recovery process does not provide healing; sotware or hardware component

    remains deective and may cause repeated ailures i it experiences the same condition again The

    root cause or the ailure needs to be tracked and eliminated, either through a sotware fx or a

    hardware replacement

    Traditionally, this bug investigation begins with a technical assistance center (TAC) ticket opened by

    a customer and requires intensive interaction between the customer and vendor engineers Once

    identifed, the problem is usually resolved through a work-around, sotware upgrade or hardware

    replacement, all o which must be perormed manually

    Since the early days o JUNOS sotware, Juniper Networks routers were designed to include the built-

    in instrumentation needed to diagnose and remedy problems quickly Reecting Junipers origins as

    a carrier-class routing company, every JUNOS sotware system in existence comes with an extensive

    array o sotware and hardware gear dedicated to device monitoring and analysis Juniper has been

    a pioneer in the industry with innovations such as persistent logging, automatic core fle creation

    and development tools (such as GDB) embedded in JUNOS sotware, all acilitating ast deect tracing

    and decision making) In the traditional support model, customers and Juniper Networks TAC (JTAC)

    engineers jointly use those tools to zero in on a possible issue and resolve it via confguration change

    or sotware fx

    In many cases, this is enough to resolve a case in real time, as soon as the deect traces are made

    available to Juniper Networks Customer Support

    However, Juniper would never have become a market leader without a passion or innovation We

    see routing systems with embedded intelligence and sel-healing capabilities as the tools or ensuringsurvivability and improving the user experience Going ar beyond the automated hardware sel-

    checking normally available rom many vendors, JUNOS sotware can not only collect data and

    analyze its own health, but can also report this state back to the customer and to the JTAC with the

    patent-pending Advanced Insight Service (AIS) technology As a result, the router that experiences

    problems can get immediate vendor attention around the clock and without involving NOC personnel

    A support case can be automatically created and resolved beore operators are aware o the issue I a

    code change is needed, it will go into the next maintenance or major JUNOS sotware release and will

    be available through a seamless upgrade on the router This cycle is the basis o sel-healing JUNOS

    sotware operation and paves the way to dramatic OPEX savings or existing networks

    The main dierence between AIS and similar call-home systems is the degree o embedded intelligence

    AIS-enabled JUNOS sotware both monitors itsel or apparent ailures such as a process crash or laser

    malunction and proactively waits or early signs o problems such as degrading storage perormanceor increasing number o unresolved packets in the orwarding path Triggered and periodic health

    checks are continuously improved based on actual feld cases encountered and resolved by the JTAC,

    thus integrating the collective human expertise into the running o JUNOS sotware systems Further,

    AIS is ully programmable with new health metrics and triggers that customers can add Better yet, in

    its basic orm, AIS comes with every JUNOS sotware systemor ree

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 21

    Network Operating System Evolution


    An oten orgotten but very important aspect o unctional separation is the capability to troubleshoot

    and analyze a production system As the amount o code that constitutes a network operating

    system is oten measured in hundreds o megabytes, sotware errors are bound to occur in even the

    most robust and well-regressed designs Some errors may be discovered only ater a huge number

    o protocol transactions have accumulated on a system with many years o continuous operation

    Deects o this nature can rarely be predicted or uncovered even with extensive system testing

    Ater the error is triggered and the damage is contained by means o automatic sotware recovery,

    the next step is to collect the inormation necessary to fnd the problem and to fx it in the production

    code base The speed and eectiveness o this process can be critical to the success o the entire

    network installation because most unresolved code deects are absolutely not acceptable in

    production networks

    This is where proper unctional separation comes into major play When a sotware deect is seen, it

    is likely to become visible via an error message or a aulty process restart (i a process can no longer

    continue) Because uptime is paramount to the business o networking, routers are designed to restart

    the ailing subsystem as quickly as possible, typically in a matter o milliseconds

    When this happens, the original error state is lost, and sotware engineers will not be able to poke

    around a live system or possible root causes o the glitch Unless the deect is trivial and easilyunderstood, code designers may take some time to recreate and understand the issue Osite

    reproduction can be challenging, because replicating the exact network conditions and sequence

    o events can be difcult, and sometimes impossible In this case, the post-mortem memory image

    (core dump) o the ailing process is indispensable because it contains the state o data structures and

    variables, which can be examined or integrity It is not uncommon or JUNOS sotware engineers to

    resolve a deect just by analyzing the process core dump

    The catch here is that in tightly coupled processes, the ailure o one process may actually be

    triggered by an error in another process For example, RSVP may accept a poisoned trafc

    engineering database rom a link-state IGP process and subsequently ail I the processes run in

    dierent memory spaces, RSVP will dump the core, and IGP will continue running with a aulty state

    This situation not only hampers troubleshooting, but also potentially brings more damage to the

    system because the state remains inconsistent

    The issue o proper unctional separation also has implications or sotware engineering managers It

    is a common practice to organize development groups according to code structure, and interprocess

    sotware deects can become difcult to troubleshoot because o organizational boundaries Improper

    code structure can easily translate into a TAC nightmare, where a deect is regularly seen in the

    customer network, but cannot be reliably reproduced in the lab or even assigned to the right sotware

    engineering group

    In JUNOS sotware, the balance between the amount o restartable code and the core dump is tuned

    to improve troubleshooting and ensure quick problem resolution JUNOS sotware is intended to be a

    robust operating system and to deliver the maximum amount o inormation to engineering should

    an error occur This design helps ensure that most sotware deects resulting in code restarts are

    resolved within a short time period, oten as soon as the core fle is delivered

    Quality and Reliability

    System integrity is vital, and numerous engineering processes are devoted to ensuring it The

    ollowing section touches on the practice o quality sotware products design

    System Integrity

    I you were curious enough to read this paper up to this point, you should know that a great deal

    o work goes into the design o a modern operating system Constant eature development and

    inrastructural changes mean that each new release has a signifcant amount o new code

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.22

    Network Operating System Evolution

    Now you might ask i the active development process can negatively aect system stability

    With any legacy sotware design process, the answer would be defnite: Yes

    The phenomenon known to programmers as eature bloating is generally responsible or degrading

    code structure and clarity over time As new code and bug fxes are introduced, the original design

    goals are lost, testing becomes too expensive, and the release process produces more and more

    toxic builds or otherwise unusable sotware with major problems

    This issue was recognized very early in the JUNOS sotware development planning stage

    Back in 1996, automated system tests were not widely used, and most router vendors crated their

    release methodology based on the number o changes they expected to make in the code Typically,

    every new sotware release would come in mainstream and technology versions, with the ormer

    being a primary target or bug fxes, and the latter receiving new eatures Deects were caught

    mainly in production networks ater attempts to deploy new sotware, which resulted in a high

    number o bug fxes and occasional release deerrals

    To satisy the needs o customers looking or a stable operational environment, general deployment

    status was used to mark sae-harbor sotware trains It was typically awarded to mainstream code

    branches ater they had run or a long enough time in early adopters networks

    As a general rule, customers had to choose between eatures and stability Technology and earlydeployment releases were notoriously problematic and ull o errors, and the network upgrade

    process was a trial-and-error operation in search or the code train with a right combination o

    eatures and bugs

    This approach allowed router vendors to avoid building extensive test organizations, but generally led

    to low overall product quality General deployment sotware trains lingered or years with almost no

    new eatures, while technology builds could barely be deployed in production because o reliability

    problems Multiple attempts to fnd the balance between the two made the situation even worse due

    to introduction o even more sotware trains with dierent stability and eature levels

    This practice was identifed as improper in the edgling JUNOS sotware design process Instead, a

    state-o-the-art test process and pioneering release methodology were born

    Each JUNOS sotware build is gated by a ull regression run that is ully automated and executes orseveral days on hundreds o test systems simulating thousands o test cases These test cases check

    or eature unctionality, scaling limits, previously known deects and resilience to negative input

    (such as aulty routing protocol neighbors) I a ailure occurs in a critical test, the fnal product will

    not be shipped until the problem is fxed This process allows JUNOS sotware releases to occur on a

    predictable, periodic basis In act, many customers trust JUNOS sotware to the point that they run

    the very frst build o each version in production Still, every JUNOS sotware version is entitled to the

    so-called regression run (i requested by customers) A regressed release is a ully tested original build

    with all latest bug fxes applied

    The JUNOS sotware shipping process is based on several guiding principles:

    Every JUNOS sotware release is gated by a systems test, and no releases with service-

    aecting issues are cleared or shipment

    Regressed (maintenance) releases, by rule, deliver no new eatures For example, no eatures

    were introduced between JUNOS sotware 85R1 and 85R2

    As a general rule, eature development happens only at the head o the JUNOS sotware train

    Experimental (engineering) branches may exist, but they are not intended or production

    No eature backports are allowed (that is, eatures developed or rev 92 are not retroftted into

    rev 85)

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 23

    Network Operating System Evolution

    No special or customer-specifc builds are allowed This restriction means JUNOS sotware

    never receives modifcations that are not applicable to the main code base or cannot pass the

    system test Every change and eature request is careully evaluated according to its value and

    impact worldwide; the collective expertise o all Juniper Networks customers benefts every

    JUNOS sotware product

    This release process ensures the exceptional product quality customers have come to expect rom

    Juniper over the years Although initially met with reluctance by some customers accustomed to therandomly spaced, untested and special builds produced by other vendors, our release policy ensures

    that no production system receives unproven sotware Customers have come to appreciate the

    stability in OS releases that Junipers approach provides

    With its controlled release paradigm, Juniper has set new standards or the entire networking

    industry, The same approach was used later by many other design organizations

    However, the JUNOS sotware design and build structure remains largely unmatched

    Unlike competitors build processes, our build process occurs simultaneously or all Juniper Networks

    platorms and uses the same sotware repository or all products Each code module has exactly one

    implementation, in both shared (common) and private (platorm-specifc) cases Platorm-specifc and

    shared eatures are merged during the build in a well-controlled and modular ashion, thus providing

    a continuous array o unctionality, quality and experience across all JUNOS sotware routing,switching and security products

    Release Process Summary

    Even the best intentions or any sotware development are inadequate unless they can prove

    themselves through meaningul and repeatable results At Juniper, we frmly believe in a strong

    link between sotware quality and release discipline, which is why we have developed criteria or

    meetingor ailingour own targets

    Here is a set o metrics or judging the quality o release discipline:

    Documented design process: The Juniper Networks sotware design process has met the

    stringent TL9000 certifcations requirements

    Release schedule: JUNOS sotware releases have been predictable and have generally occurred

    every three months An inconsistent, unpredictable or repeatedly slipping release process

    generally indicates problems in a sotware organization

    Code branching: This is a trend where a single source tree branches out to support either

    multiple platorms or alternative builds on the same platorm with unique sotware eatures

    and release schedules Branching degrades system integrity and quality because the same

    unctionality (or example, routing) is being independently maintained and developed in

    dierent sotware trains Branching is oten related to poor modularity and can also be linked

    to poor code quality In an attempt to satisy a product schedule and customer requirements,

    sotware engineers use branching to avoid eatures (and related deects) that are not critical to

    their main target or customer As a result, the feld ends up with several implementations o

    the same unctionality on similar or even identical hardware platorms

    Although JUNOS sotware powers many platorms with vastly dierent capabilities, it is always

    built rom one source tree with core and platorm-specifc sections The interace between the

    two parts is highly modular and well documented, with no overlap in unctionality There is no

    branching in JUNOS sotware code

    Code patching: To speed deect resolution, some vendors provide code patching or point

    bug-fx capability, so that selected deects can be patched on a running operating system

    Although technically very easy to do, code patching signifcantly degrades production sotware

    with uncontrolled and unregressed code inusions Production systems with code patches

    become unique in their sotware state, which makes them expensive to control and maintain

    Ater some early experiments with code patching, JUNOS sotware ceased this process in

    avor o a more comprehensive and coherent ISSU and nonstop routing implementation

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc.24

    Network Operating System Evolution

    Customer-specifc builds: The use o custom builds is typically the result o ailures in a

    sotware design methodology and constitutes a orm o code branching I a eature or specifc

    bug fx is o interest to a particular customer, it should be ported to the main development

    tree instead o accommodated through a separate build Code branching almost inevitably has

    major implications or a product such as insufcient test coverage, eature inconsistency and

    delays JUNOS sotware is not delivered in customer-specifc build orms

    Features in minor (regressed) releases: Under Junipers release methodology, which has been

    adopted by many other companies, minor sotware releases are regressed builds that almost

    exclusively contain bug fxes Sometimes the bug fx may also enable unctionality that

    existed but was not made public in the original eature release However, this should not be

    a common case I a vendor consistently delivers new unctionality along with bug fxes, this

    negatively aects the entire release process and methodology because subsequent regressed

    releases may have new caveats based on the new eature code they have received

    Final Product Quality and Stability

    Good code quality in a network operating system means that the OS runs and delivers unctionality

    without problems and caveatsthat is, it provides revenue-generating unctionality right out o

    the box with no supervision Customers oten measure sotware quality by the number o deects

    they experience in production per month or per year In the most severe cases, they also record the

    downtime associated with sotware deects

    Generally, all sotware problems experienced by a router can be divided into three major categories:

    Regression deects are those introduced by the new code; a regression deect indicates that

    something is broken that was working beore

    Existing sotware deects are those previously present in the code that were either unnoticed

    or (up to a certain point) harmless until they signifcantly aected router operation

    New eature allouts are caveats in new code

    Junipers sotware release methodology was created to greatly reduce the number o sotware deects

    o all types, providing the oundation or the high quality o JUNOS sotware Regression deects are

    mostly caught very early in their lietime at the oreront o the code developmentExisting sotware deects represent a more challenging case JTAC personnel, SE community or

    customers can report them

    Some deects are, in act, uncovered years ater the original design The verity that they were not

    ound by the system test or by customers typically means that they are not severe or that they occur

    in rare circumstances, thus mitigating their possible impact For instance, the wrong integer type

    (signed versus unsigned) may aect a 32-bit counter only when it crosses the 2G boundary Years o

    uptime may be needed to reveal this deect, and most customers will never see it

    In any case, once a new deect class is ound, it is scripted and added to the systest library o test

    cases This guarantees that the same deect will not leak to the feld again, as it will be fltered out

    early in the build process This systest library, along with the JUNOS sotware code itsel, is among

    the crown jewels o Juniper intellectual property in the area o networking

    As a result, although any signifcant eature may take several years o development, Juniper has

    an excellent track record or making sure things work right at the very frst release, a record that is

    unmatched in the networking industry

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008, Juniper Networks, Inc. 25

    Network Operating System Evolution


    Designing a modern operating system is a difcult task that challenges developers with complex

    problems and choices Any specifc eature implementation is rarely perect and oten strikes a subtle

    balance among a broad range o reliability, perormance and scaling metrics

    This balance is something that JUNOS sotware developers work hard to deliver every day

    The best way to appreciate JUNOS sotware eatures and quality is to start using JUNOS sotware

    in production, alongside any other product in a similar deployment scenario At Juniper Networks,

    we go beyond what others consider the norm to ensure that our sotware leads the industry in

    perormance, resilience and reliability

    What Makes JUNOS Software Different


    Feature Benefts to Customer

    JUNOS software development efforts 19962008

    Unmatched experience and expertise

    Open-software policy SDK, custom programming and scripting

    Self-healing Automatic core processing and Advanced Insight Solution eature

    Scaling down Low-end systems with JUNOS sotware onboard

    Scaling up TX Matrix platorm, 32,000 logical interaces, 4000 BGP peers, and 4000

    VPN routing and orwarding (VRF) tables

    Nonstop operation Unifed ISSU and nonstop routing or all code revisions

    Intelligent thread scheduling No process deadlocks under all circumstances

    Strict engineering and release discipline Code quality, no regressions, and eatures on time

    Predictability: JUNOS Sotware Releases 20042008

    Jan Apr Jul Oct Jan Apr Jul Oct Jan Apr Jul Oct Jan Apr Jul Oct Jan Apr Jul Oct Jan

    Junos 7.5


    Junos 7.8


    Junos 8.1


    Junos 8.4


    Junos 9.1


    Junos 7.4


    Junos 7.7


    Junos 8.0


    Junos 8.3


    Junos 9.0


    Junos 7.3


    Junos 7.6


    Junos 7.9


    Junos 8.2


    Junos 8.5


    2004 2005 2006 2007 2008

  • 8/2/2019 JUNOS Archtecture


    Copyright 2008 Juniper Networks, Inc. All rights reserved. Juniper Networks,

    the Juniper Networks logo, NetScreen, and ScreenOS are registered trademarks

    o Juniper Networks, Inc. in the United States and other countries. JUNOS and

    JUNOSe are trademarks o Juniper Networks, Inc. All other trademarks, service

    marks, registered trademarks, or registered service marks are the property o

    their respective owners. Juniper Networks assumes no responsibility or any

    inaccuracies in this document Juniper Networks reserves the right to change




    Juniper Networks, Inc.

    1194 North Mathilda Avenue

    Sunnyvale, CA 94089 USA

    Phone: 888.JUNIPER (888.586.4737)

    or 408.745.2000

    Fax: 408.745.2100



    Juniper Networks, Inc.

    10 Technology Park Drive

    Westord, MA 01886-3146 USA

    Phone: 978.589.5800

    Fax: 978.589.0800


    Juniper Networks (Hong Kong) Ltd.

    26/F, Cityplaza One

    1111 Kings Road

    Taikoo Shing, Hong Kong

    Phone: 852.2332.3636

    Fax: 852.2574.7803



    Juniper Networks (UK) Limited

    Building 1

    Aviator Park

    Station Road


    Surrey, KT15 2PG, U.K.

    Phone: 44.(0).1372.385500

    Fax: 44.(0).1372.385501

    To purchase Juniper Networks solutions, please

    contact your Juniper Networks sales representative

    at 1-866-298-6428 or authorized reseller.

    Network Operating System Evolution

    About Juniper Networks

    Juniper Networks, Inc is the leader in high-perormance networking Juniper oers a

    high-perormance network inrastructure that creates a responsive and trusted environment

    or accelerating the deployment o services and applications over a single network This uels

    high-perormance businesses Additional inormation can be ound at wwwjunipernet