- Software architecture
-Junos OS is modular – compartmentalised into multiple processes each with their own memory space. The idea behind this is that new features can be added at lower risk of breaking existing functionality, and that if once process fails other processes may not.
-Junos is built on either a modified version of FreeBSD or Linux.
-All Junos devices use the same source code base across platform specific images. This attempts to ensure consistency across devices. (Admittedly this is not the case with Cisco, though they look similar – between generations there is massive difference in how different devices work.)
-Claims to be set apart from other network OS’ as it is one software system, delivered over one software release track, and with one modular architecture.
The utility of this modular approach is clear, if for instance the SNMP daemon fell over, it would not stop the RPD (Routing Protocol process) from functioning, so the whole unit will not stop working.
Overview of Junos Devices:
There are Junos devices responsible for: Switching, Routing and Security. All three types of Juniper devices run using Junos OS. It provides consistent end-to-end IP infrastructure both in small enterprise environments and large ISP networks.
Routing Devices:
-(Very oldschool, M series was the first product offering, it’s a standard router, Service provider focused, no switching), was replaced by the t series which had more bandwidth.etc.
-PTX series – Provides up to 460 TBps of throughput in a single chassis. Products designed to the service providers core. Top end equipment.
-MX series – Provides up to 80Tbps of aggregate half duplex throughput. It was designed with providers edge services in mind in medium to large POPs and large enterprise environments.
–ACX Series – These devices are for simple end-to-end provisioning, and support L2 and L3 functionality IP/MPLS traffic engineering.
Switching Devices:
–EX Series- These switches provide up to 13.2 Tbps of throughput. Designed for access aggregation and core deployments. They are targeted at enterprise and data center environments.
–QFX Series- Provide wire speeds of 10/25/40/100 GbE throughput. For use in data center environments – provides a ready solution. Super fast.
Security Devices:
-SRX Series- The primary product line that run Junos OS, provide up to 2tbps of firewall throughput. Designed to meet security requirements of managed service deployments and security services in the enterprise and ISP world.
SDN Devices:
Juniper have also started offering a number of cloud based platforms called SDN (Software-Defined networking) products, using the same modular methodology, but with virtualised components on the control and data planes.
–Contrail – Adopted by the Linux network foundation, helping open source projects – allows Junipers to take lots of VM’s and start managing SDN style the connectivity between those VM’s wherever they are.
–NFC250- Effectively a hypervisor that can have VMs run on them, glued to a switch. Good for network virtualisation.
–Northstar Controller- Used to manage traffic engineering, taking something like RSVP-TE to the next level and it can all be run from a centralised point. From there we can plot, record and manage the path through the network.
–IP/MPLSView– If modelling in Northstar how our traffic is being engineered and what paths are being taken: this gives feedback into what would happen in certain failure scenarios. Allows collection of telemetry from Juniper devices, model the network based on realtime information and then play games – what if this link fails, or what if all these links fail because a fibre goes down. This can be simulated and then looking at the stats fed into that – what the traffic flows would look like. Would we see congestion, where would the traffic be diverted to.
Software-programmable infrastructure that doesn’t need to be on a dedicated physical device. Junos OS can also run as a VM using either VMware or kernel-based virtual machine (KVM) as the host software.
Increasingly Juniper are moving their products into the virtual space, we want the ability to start on demand virtual networking devices wherever we need them. Could be a vSRX Virtual Firewall (cloud security for a branch in a VM format) or Virtual MX which is carrier-grade virtual routing for enterprise/ISPs.
- Control and forwarding planes
The Control plane, and the forwarding plane (also known as the data plane) are separate processes, in keeping with the modular theme of the OS.
So: The processes that control routing and switching are separated from the processes that forward frames, packets or both, and is one of the key reasons Junos OS can support so many different platforms.
- Routing Engine and Packet Forwarding Engine
Basic view of Junos Architecture, in the same chasis:
Routing Engine (RE) performs control plane functions of a device. It is the ‘brain’ of the platform responsible for performing protocol updates and system management. The processes run in this are in a protected memory environment unique to the routing engine. (Based on X86/PowerPC Architecture depending on the platform)
RE Maintains:
–Routing table
-Bridging table
-Primary Forwarding Table
RE Handles all protocol processes, some software processes that can control the devices interfaces, the chassis component system management and user access to the device.
These software processes run ontop of the Junos kernel, which interacts with the PFE. The software directs all protocol traffic from the network to the RE for the required processing.
The Routing Engine also provides the CLI in addition to the j-web GUI. These user interfaces run on top of the Junos Kernel and provide user access and control over the device.
The RE also controls the PFE by providing accurate, up to date L2 and L3 Forwarding tables and by downloading microcode and managing software processes that reside in the PFE‘s ‘microcode’. The RE receives hardware and environmental status message from the PFE and the acts on them as appropriate.
The modular Software architecture design allows the incorporation of high availability features suck as:
-Graceful Routing Engine Switchover (GRES)
-NonStop active Routing (NSR)
-unified-In-Service Software Upgrades (ISSUs)
It connects to the Packet Forwarding engine (PFE) through an internal link, usually on separate hardware.
PFE Responsible:
-Forwarding transit traffic from the device
-Uses Application-Specific integrated circuits (ASICs)
-Receives Primary Forwarding Table from RE through the internal link
It forwards traffic based on its local copy of the forwarding table, which is a synchronized copy of the FT on the information created by and provided by the RE. Using a local copy of the forwarding table means that the PFE doesn’t need to consult the RE every time it makes a forwarding decision which saves both on time and processing. It also allows platforms to keep forwarding traffic in the even there is RE instability. The PFE also maintains L2 forwarding information.
In addition to forwarding traffic the PFE also implements services such as:
-Policers
-Stateless Firewall Filters
-Class of Service (CoS)
Other services are available through special cards you can add to the PFE.
So the RE does the intelligent stuff, laying out the instructions, and the PFE is the workhorse that follows those instructions, forwarding frames, packets or both.
3 components of the PFE with ASICs:
-Switching Control Board
-Physical Interface Card (PIC)
-Flexible PIC Concentrator (FPC)
- Transit traffic processing
Transit Traffic refers to all traffic that flows in through a network ingress port. It is compared to the forwarding table entries and is then passed onto through a network egress port towards its destination.
In order for a device to forward any frames a Forwarding Table entry must exist for that destination. (the vast majority of packets are Transit Traffic). The forwarding table can be viewed with the command:
show route forwarding-table
Transit traffic passes only through the forwarding plane, and is never sent to or processed by the control plane.
By processing transit traffic only in the forwarding plane platforms running Junos OS aim to have predictable performance rates.
Transit traffic can be both Unicast and Multicast traffic.
Unicast enters one ingress port and is transmitted out a single egress port towards its destination.
Multicast transit traffic also enters the device through a single ingress port which is then replicated and sent out multiple egress ports (depending on the number of multicast receivers and the network environment).
- Exception traffic
Exception traffic does not pass through the local device. It requires special handling.
Examples of exception traffic:
-Packets addressed to the chassis such as routing protocol updates, Telnet sessions, pings, traceroutes and replies to traffic sourced from the RE. Reserve address Multicast Packets, such as destinations for OSPF traffic would fall under this umbrella, and then get sent to the RE (RDP).
-IP packets with the IP options held (options in the packets IP header are rarely seen, but the PFE was purposely designed to handle IP options. Packets with IP options must be sent to the RE for processing)
-Traffic that requires the generation of Interne Control Message Protocol(ICMP) messages. ICMP messages are sent to the packet’s source to report various error conditions and to respond to ping requests.
Examples of ICMP errors include destination unreachable messages, which are sent when no entry is present in the forwarding table or the packet’s destination address, and time-to-live (TTL) expired messages, which are sent when a packet’s TTL is decremented to zero. In this case the PFE process handles the generation of ICMP messages.
Junos OS sends all exception traffic destined for the RE over the internal link that connects the Control and Forwarding planes. Junos OS limits traffc crossing the control plane/forwarding plane divide to avoid Denial of Service attacks. When congestion is high Junos OS gives preference/priority to the control traffic destined for the RE. This built in rate limiter is not configurable.
Junos System Daemons
RPD Looks after the routing table (RIB – default inet.0 contains all routes), then passes routes onto the forwarding table (FIB), updating things like shortest path topology and protocols. Very important daemon.
MGD – Management Daemon, if you SSH or Telnet into the box, or start some kind of CLI, the MGS is responsible for spawning it, handling the initial login requests, any show commands, power off, power on.etc is also fed back to MGD which then gets processes done. So CLI interaction goes through the MGD, as are xml replies when dealing with automated processes. It mediates our dealings with the system we are managing.
DCD – Device configuration daemon, if you create and interface, make changes/configure an ipv4 address, subinterfaces, vlans, anything like that – DCD is responsible for programming that interface.
Can view log files for DCD (show log dcd) to see a record of interface creation.
CHASSISD – Manages the process of what goes on with the other hardware on the device. It makes the connection across the internal Ethernet switch to each of the FPC’s (Flexible Pic Concentrators, basically line cards) that allows the RE to program and control the line card in the box.
There are dozens of processes that happen in the RE, such as VRPD Class Of Service Daemon and SNMPD but those are some of the most important ones.