Juniper has taken the wraps off new software and switches that are designed to broaden user options in deploying software-defined branch offices and enterprise networks.
The
company bolstered its Contrail SD-WAN cloud package to include support
for SD-LAN-specific operations, such as provisioning of new devices and
managing branch office LANs.
"From one cloud portal, customers can now provision Juniper
EX Series switches to manage LAN fabrics and configure LAN
virtualization and security policies in the same way they operate their
SD-WAN environments," wrote Manoj Leelanivas, chief product officer at
Juniper, in a blog
about the enhancements. "This automated functionality simplifies
operations to reduce costs, streamline workflows and leverage the WAN
and LAN network for connected security. In addition to the cloud-managed
SD-WAN solution, these features will also be in the downloadable
controller software for optional on-premises deployment."
The Contrail SD-WAN cloud offering, announced earlier this year, expanded on the company’s existing on-premise (SRX-based) and virtual (NFX-based)
SD-WAN offerings to include greater expansion possibilities – up to
10,000 spoke-attached sites and support for more variants of passive
redundant hybrid WAN links – and topologies such as hub and spoke,
partial, and dynamic full mesh, Juniper stated.
The service
brings with it Juniper’s Contrail Service Orchestration package, which
secures, automates, and runs the service lifecycle across NFX Series Network Services Platforms, EX Series Ethernet Switches, SRX Series next-generation firewalls, and MX Series 5G Universal Routing Platforms. Ultimately it lets customers manage and set up SD-WANs, and now LANs, all from a single portal.
That
same portal can be used to show Mist wireless access points and launch
the Mist cloud for WLAN provisioning, troubleshooting, management and
other day-to-day operations, including Juniper's wired/wireless
assurance capabilities, Leelanivas stated. Juniper in April closed the
agreement to buy wireless-gear-maker Mist for $405 million and has been
incorporating the Mist technology with its own.
Mist
is known for its cloud-managed, AI-based wireless service called WiFi
Assurance, which measures performance and service-level metrics to make
wireless networks more predictable and reliable, according to the
company. Mist's cloud-based system features an AI-driven technology,
called Marvis, that brings dynamic packet-capture and machine-learning
technology to automatically identify, adapt and fix network issues.
Juniper recently announced
Mist is expanding its cloud-based Assurance program to include wired
platforms. Wired Assurance can tap into Juniper’s core network operating
system, Junos, and gather telemetry data that will measure network
performance for connected endpoints, including IoT devices, the company
said. It also features anomaly detection to alert when there is a
deviation in switch performance from baseline metrics before users know
issues exist.
On the hardware side, Juniper expanded its branch switching options to include:
NFX350: The NFX350
family features eight 10G and eight 1G interfaces and, depending on the
configuration, up to 2TB of storage, 128GB of RAM and 32 vCPUs. The
fully loaded NFX350 will support up to 40Gbps of NG-firewalling and up
to 8Gbps of IPSec.
SRX380: The SRX380
comes with several key performance features, including 1Gbps IPsec
performance, four 10G ports, 16 PoE+ ports for greater wattage and
density, AES256 MACsec encryption and four mini-card slots for expanded
connectivity.
A new Wi-Fi card for branch SRX boxes that lets customers deploy
Wi-Fi with zero-touch configuration alongside LTE, Ethernet and other
traditional network transport options.
This story, "Juniper broadens SD-Branch management, switch options" was originally published by
Network World.
JTAC recommended versions
of Junos software are listed to assist with determining which version
of software to download and install.
This article applies to the following devices:
EX Series
M, T, and MX Series
ACX Series
QFX Series
SRX Series
For other Junos devices, refer to the Release Notes and the Alerts column on the Download Software pages. Note: To be automatically notified of updates to this document,
use the Subscribe link in the toolbox on the right of the page. If you
do not see the Subscribe link, log in with your user account. Important Software Upgrade Notification Before loading a software release, Juniper
recommends that you read the associated Release Notes to understand how
features, functionality, fixes and any known outstanding issues will
apply to your specific network and applications. A second sensible
recommendation is for you to test the release in your lab whereby you
emulate your topology and traffic flows where possible to further
understand how your network will perform with the new release in your
unique environment. Juniper
offers optional services to aide customers in selecting and testing
software releases. If interested in more information, please contact
your Juniper Sales Representative to discuss offerings and pricing.
Symptoms:
For customers planning an
upgrade or initial installation, JTAC recommends the Junos software
versions in this article. These versions are selected using input from
Juniper Engineering, customers, and analysis of field usage data.
Exceptions to this include:
JTAC has specifically recommended that customers use a version of Junos software that is different from what is listed.
You require specific features (Feature Explorer)
that are available only in another version of Junos software. In this
case, be sure to download the latest maintenance release.
Your currently installed version of Junos is working well.
If you use NSM, refer to the NSM & Junos Compatibility Matrix to make sure the recommended Junos software version can be managed by NSM.
To see the list of End of Engineering (EOE) and EOS (End of Support)
dates for specific Junos versions, please go to the Junos Dates &
Milestones page: https://support.juniper.net/support/eol/software/junos/
To see features supported per specific Junos versions, please go the
Juniper Pathfinder page and navigate to "Feature Explorer": https://apps.juniper.net/home/
Solution:
To download Junos Software, go to the Software Download site and find your product.
The JTAC Recommended Junos Releasesare in the tables below.
NOTE: To locate a Junos release containing an 'S' (i.e. Junos 17.3R3-S3), on the Software Download product page change the OS drop-down from Junos to Junos SR
It is highly recommended to refer to the Release
Notes, Technical Documentation, and KB articles for any outstanding and
resolved issues before making the upgrade decision. Contact JTAC if
there are any queries.
Please refer to TSB16758 for minimum software requirements for newer revision EX8200 linecards.
Junos 12.3R3 and 12.3R4 are not recommended for deployment on MX5, MX10, MX40, MX80, and all MX-3D FPC. See PR896592 or contact JTAC for additional information.
To obtain the specified Service Release, please contact JTAC.
This includes subscriber management deployments that incorporate services such as CGNAT, etc.
This release is also recommended for deployments that include both MS-MPC/MIC and MS-DPC modules within the same chassis.
See KB33938 for detail information and directly downloadable links to software for M/MX/PTX/T-Series JUNOS Software
KB29651 - Unable to
upgrade from Junos OS 12.1X46 to subsequent releases of Junos OS on
SRX5400/5600/5800 platforms due to "The /cf filesystem is low on free
disk space" on SRX5k RE-13-20.
TSB16905 - On SRX
High-End platforms, when NAT is configured, ISSU upgrade from
12.1X46-D40 to any higher releases results in loss of security policies.
PR1458501
- On SRX5000 series with SRX5k RE-13-20 a software upgrade to Junos
12.3X48-D80 and higher releases may fail the pre-check due to
insufficient space available on the compact flash. Workaround is to use
the USB install-media or first downgrade to 12.3X48-D10 and then upgrade
to the target release.
Notes for upgrading from Junos 15.1X49 releases to 18.2R3 or 18.2R3 based Service Releases:
Junos OS upgrade from 15.1X49 directly to 18.2R3 or 18.2R3 based
Service Releases is supported for all SRX platforms, except vSRX. To
upgrade vSRX from 15.1X49 to higher versions, deploy a new vSRX VM.
ISSU is not supported when upgrading from Junos 15.1X49 to higher versions.
KB34945
- When Junos Space Security Director is used for managing the SRX
configuration and the AppFW, IDP or UTM features are used, then when
upgrading to Junos 18.2R1 or higher, the SRX configuration needs to be
migrated to the new Unified Policies style and Security Director version
19.3 or higher is required.
When upgrading from Junos 15.1X49-D170 to Junos 18.2 releases, the following features will not be available after the upgrade:
GTP Inspection - GTP tunnel enhancements (SRX1500, SRX4100,
SRX4200, SRX5400, SRX5600, SRX5800, and vSRX instances). This feature
was introduced in 15.1X49-D140 and 18.3R1 and higher releases.
The following CSO / SD-WAN related features:
Application-based multipath support (SRX Series and vSRX)
Application quality of experience scaling support (SRX4100, SRX4200)
AppQoE support in high availability mode (SRX4100, SRX4200)
Application path selection based on link preference and priority
(SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 SRX4200, and
vSRX)
Virtual routing and forwarding instances security features
support (SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100,
SRX4200, and vSRX)
2019-09-30: Updated
SRX4600, SRX5k-SPC3, SRX200, 300, 550(M), 650 series and SRX1k/3k, added
new entries for the vSRX 3.0 and SRX5k RE3/IOC4/SCB4
2019-07-25: Updated MX Subscriber and MX Services information
2019-07-21: Adding "Important Software Upgrade Notification" in the beginning
2019-06-25: Add a link to KB33938 for details of M-Series, MX-Series, PTX-Series, and T-Series
2019-04-25: Corrected SRX download links
2019-04-16: Updated SRX releases
2019-04-10: Fixed QFabric and EX6200 links.
2019-03-19: Removing EOL released from M-series, and T-series
2019-03-01: Added note on how to locate Junos release versions containing an 's'
2019-02-28: Updated for several SRX platforms; added link to Feature Explorer.
2019-01-30: Fixed broken links for MX and vMX.
2018-12-19: Updated JRR for SRX5k with SPC3
2018-10-15: Updated SRX JRR versions and removed SRX210B and SRX210H platforms due to EOS reached.
2018-10-05: SRX: Move direct link to JRR version to the middle column that references JRR version
2018-10-03: SRX: Added direct link to JRR version per platform
2018-09-26: Removed J-Series platforms, due to EOS reached.
2018-06-25: Updated releases for ACX, MX and vMX platforms.
2018-05-17: Corrected link to SRX4600's software download page.
2018-05-15: Updated the recommended release for ACX5048 / ACX5096
2017-11-16: Updated VRR to 16.2
2017-04-18: Added jump links for quick access to platform series sections
Migrating your data to the cloud can be a daunting task
if your enterprise doesn’t adequately prepare for it. Cloud migration
can be a lengthy process, and it requires a large time and financial
investment from your company to fulfill. Without a well thought-out
migration strategy in place, your business will have a tough time
adopting the cloud into your infrastructure.
How do you design a successful cloud migration strategy? What are the key factors of cloud migration
that this strategy should address? Most importantly, how does your
business achieve the cloud migration goals you’ve set out? Below, we
list several tips for creating and executing a successful cloud
migration strategy.
Understand why you want to migrate to the cloud
First things first: why do you want to
move your enterprise’s data and workflows to the cloud? The cloud is an
exciting technology that businesses want to take advantage of. However,
without a clear reason behind adopting the cloud into your
infrastructure, your cloud migration is destined to crash and burn. Your
enterprise needs to understand what it seeks to accomplish by moving to
the cloud. Whether it be to reduce costs or to take advantage of
cloud-based services, your cloud goals allow you to design your
migration strategy around your specific business needs.
Know what data should be included in your migration strategy
Your business doesn’t necessarily need to
move all of its data onto the cloud. If you want to take advantage of
the computing power the cloud provides to build powerful applications
and solutions, for example, you won’t need to migrate your legacy
business data over. Alternatively, businesses that want to use the cloud
for data storage must consider which bits of data should remain
on-premise and which should be exclusively in the cloud.
Plan your cloud migration in stages
Fully migrating your data to the cloud
can take a long time, especially for enterprises that store a ton of
data in their infrastructure. Because it takes so long to move this
data, your migration strategy should move data onto the cloud in stages.
Non-essential data should be migrated first because you’ll likely be
unfamiliar with the cloud environment you’re migrating to. If you
attempt to migrate mission-critical or sensitive data first and
something goes wrong (such as accidentally leaking your data), it can be
costly to your business.
Evaluate your migration strategy after a while
After you’ve started migrating data over,
it’s a good idea to look at your migration strategy and see if it’s
working for your company. This evaluation can include how much of the
migration is complete and when you expect it to be finished if you work
at your current pace. Examining your cloud migration strategy can help
your enterprise understand how well your company is achieving its cloud
goals.
Keep your employees up to speed
When you move to the cloud, you’ll need
to train your workforce on an entirely new deployment. It’s fair to
assume that many of your staff do not use cloud solutions and
environments. They can be a roadblock for successful cloud operation,
especially if they aren’t familiar with your cloud migration plan. Make
sure that your employees are familiar with your cloud migration strategy
and what your short-term and long-term goals are.
Juniper Networks has a distinguished record as a disruptor and a change leader in the networking industry.
Juniper technologies helped fuel the rapid growth of
the internet in the early 2000s by decoupling the data-plane of an IP
router from its control plane and creating routers that moved IP traffic
many times faster and more economically than before. Junos OS,
the software brain of Juniper routers, switches and security
appliances, integrated market-leading innovation into an open-source
Unix OS, namely FreeBSD. Among other things, Junos introduced innovative
ways of managing network devices, leading to standardized modeling
languages and protocols, such as YANG and NETCONF, laying the foundation
for programmability and automation that the industry has broadly
adopted today.
More recent innovations include virtualization, node slicing and the ability to support 3rd-party
white box hardware, to name a few. Furthermore, Juniper consistently
maintains a strong presence in standards bodies evangelizing open
programmability to ensure freedom of choice for the entire networking
industry.
The networking industry is in transition again with
cloud, 5G and SDN creating new challenges, as well as opportunities.
These, in turn, require new network architecture approaches. Juniper’s
engineering team has been busy designing software infrastructure to
enable new paradigms such as scale-out architectures, disaggregated and
cloud-native functions, lean and open-source compliant OS stacks, as
well as the ability to offer much greater availability, programmability,
visibility, feature development and deployment agility for operational
efficiencies in traditional deployment models. This effort has produced a
new generation of infrastructure evolution within Junos, sometimes
referred to as “Junos OS Evolved,” that imbues powerful capabilities to
the overall Junos operating system while maintaining One Junos
experience.
New Capabilities The latest Junos release incorporates the following capabilities:
Linux OS and Linux native application
components enable the user to leverage the integrated tooling and
operational mechanisms of the rich Linux open-source community
Logically centralized state database and a
publish/subscribe state distribution system for advanced observability,
troubleshooting and remediation
Model representation of the entire config and state, enabling machine-driven automation
Full software modularity with strong fault isolation boundaries for higher availability
Containerized OS components with patching and
upgrade capability for availability and run-time upgrades of on-device
software, as well as the ability to run software decoupled from hardware
in cloud-native environments
Native support for 3rd-party software agents enabling easy customization
Next generation data-plane software sub-system with a programmable and open API
Powerful and intrinsic distributed system
facility for enabling new paradigms such as distributed chassis and
cloud-hosted control planes
As software evolves, especially when it is
deployed on hundreds of thousands of devices around the globe, an
ecosystem of operational experiences, best practices, management tools
and trust also evolves around it. At Juniper, we realize the importance
of preserving the One Junos experience by keeping the following aspects
consistent across our releases:
System and application data models and interfaces via SNMP, CLI, NETCONF, Streaming Telemetry, etc.
Forwarding plane API via Openflow, P4, Advanced Forwarding Toolkit (AFT)
Key control and management plane applications
Junos OS Evolved brings powerful and innovative
new infrastructure capabilities. It enables the next generation of
network architecture deployments with the goal of meeting and exceeding
the needs and expectations of our customers well into the future.
Understanding how physical networks and virtual networks
come together to provide an end-to-end solution is critical to running
a stable production environment. The physical and virtual networks
interact with each other to provide different functionality. There
are some additional layers with the introduction of overlay networks
such as VMware NSX. This topic explains the following concepts:
VMware vSphere Architecture
The VMware vSphere architecture is very simple. There are two
ESXi hosts in a cluster called “New Cluster.” Both of
the hosts have a distributed virtual switch called “DSwitch”
with a single port group “DPortGroup” as shown in Figure 1. The cluster is assigned to a data center
called “Datacenter.”
Figure 1: VMware vSphere Architecture
All NSX appliance VMs are placed into the distributed virtual
switch “DSwitch.” The local vSwitch0 is no longer used
for any type of traffic; all underlay traffic will ingress and egress
the distributed virtual switch.
VMware NSX
To enable SDN, there are many functions from management to packet
forwarding that need to be performed. Each functional component is
described next.
VMware NSX Manager
The VMware NSX Manager provides integration with VMware vCenter
Server which allows you to manage the VMware NSX environment through
VMware vCenter. All VMware NSX operations and configuration is done
through VMware vCenter, which communicates with VMware NSX Manager
through APIs to delegate tasks to the responsible owner.
VMware NSX Controller
All virtual network provisioning and MAC address learning is
handled through the VMware NSX Controller. You can think of the VMware
NSX Controller as the virtualized control plane of the SDN network.
VMware NSX Logical Distributed Router
The VMware NSX Logical Distributed Router (LDR) is responsible
for forwarding and routing all packets through the virtualized SDN
networks. It provides the following functionality:
Default gateway for all VMs
MAC address learning and flooding
Bridging and routing all packets between different virtual
networks
Peers with the VMware NSX Edge to progress egress traffic
outside of the virtual networks
Virtual tunnel end-point (VTEP) termination
Security policies and enforcement
Multi-tenancy
The NSX LDR is a great tool for coarse or fine-grained virtual
network segmentation. Multiple VMware NSX LDRs can be created to enable
multi-tenancy or a completely separate security zone for regularity
requirements such as Payment Card Industry Data Security Standard
(PCI DSS). Each VMware NSX LDR can create virtual switches, which
are just VXLAN Network Identifiers (VNIs). You can treat virtual switches
just like you used to use VLANs in a physical network. Virtual switches
are an easy way to create multi-tiered networks for applications.
The VMware NSX LDR is split into two components: a control plane
and data plane. The control plane is responsible for the management
and provisioning of changes. The VMware NSX LDR is also installed
into each VMware ESXi host to handle the traffic forwarding and routing
as shown in Figure 2.
Figure 2: VMware NSX LDR Control Plane and Data
Plane
Each VMware host has a copy of the VMware NSX LDR running in
the hypervisor. All of the gateway interfaces and IP addresses are
distributed throughout the VMware cluster. This allows VMs to directly
access their default gateway at the local hypervisor. VMware NSX supports
three methods for MAC address learning:
Unicast—Each VMware host has a TCP connection to
the VMware NSX Controller for MAC address learning.
Multicast—The physical network – in this case,
the Virtual Chassis Fabric – uses multicast to replicate broadcast,
unknown unicast, and multicast traffic between all VMware hosts participating
in the same VNI.
Hybrid—Each VMware host has a TCP connection to
the VMware NSX Controller for MAC address learning, but uses the physical
network for local process of broadcast, unknown unicast, and multicast
traffic for performance.
If your environment is 100 percent virtualized, we recommend
that you use either unicast or hybrid mode. If you need to integrate
physical servers – such as mainframes – into the VMware
NSX virtual environment, you need to use multicast mode for MAC address
learning. Virtual Chassis Fabric allows you to configure multicast
with a single IGMP command and not have to worry about designing and
maintaining multicast protocols such as PIM.
All of the VMware NSX virtual switches are associated with a
VNI. Depending on the traffic profile, the LDR can either locally
forward or route the traffic. If the destination is on another host
or outside of the virtual NSX networks, the VMware NSX LDR can route
the traffic out to the VMware NSX Edge Gateway.
Each hypervisor has a virtual tunnel end-point (VTEP) that is
responsible for encapsulating VM traffic inside of a VXLAN header
and routing the packet to a destination VTEP for further processing.
Traffic can be routed to another VTEP on a different host or the VMware
NSX Edge Gateway to access the physical network.
In Table 1, you
can see all of the possible traffic patterns and how the VMware NSX
LDR handles them.
Table 1: Traffic Patterns
Handled by VMWare LDR
Source
Destination
Action
Local VM
Local VM, same network
Locally switch traffic
Local VM
Local VM, different network
Locally route traffic
Local VM
Remote VM, same network
Encapsulate traffic with VXLAN header and route to destination
VTEP
Local VM
Remote VM, different network
Encapsulate traffic with VXLAN header and route to destination
VTEP
Local VM
Internet
Encapsulate traffic with VXLAN header and route to VMware NSX
Edge Gateway
Local VM
Physical server outside of NSX virtual networks
Encapsulate traffic with VXLAN header and route to VMware NSX
Edge Gateway
VMware NSX Edge Gateway
The VMware NSX Edge Gateway is responsible for bridging the
virtual networks with the outside world. It acts as a virtual WAN
router that is able to peer with physical networking equipment so
that all of the internal virtual networks can access the Internet,
WAN, or any other physical resources in the network. The VMware NSX
Edge Gateway can also provide centralized security policy enforcement
between the physical network and the virtualized networks.
The VMware NSX Edge Gateway and LDR have a full mesh of VXLAN
tunnels as shown in Figure 3. This enables any
VMware ESXi host to communicate directly through the VXLAN tunnels
when they need to switch or route traffic. If traffic needs to enter
or exit the VMware NSX environment, the VMware NSX Edge Gateway removes
the VXLAN header and routes the traffic through its “Uplink”
interface and into the Virtual Chassis Fabric.
Figure 3: VXLAN Tunnels
Each virtual switch on the VMware NSX LDR needs to be mapped
to a VNI and multicast group to enable the data plane and control
plane. It is as simple as choosing a different VNI and multicast group
per virtual switch as shown in Figure 4.
Figure 4: Overlay Tunnels and Multicast Groups
As VM traffic from esxi-01 needs to reach esxi-02, it simply
passes through the VXLAN tunnels. Depending on the type of traffic,
there are different actions that can take place as shown in Table 2.
Table 2: Traffic Types and Actions
Traffic Type
Action
Unicast
Route directly to the remote VTEP through the Virtual Chassis
Fabric
Unknown Unicast
Flood through multicast in the Virtual Chassis Fabric
Multicast
Flood through multicast in the Virtual Chassis Fabric
It is possible to associate multiple VNIs with the same multicast
group; however, in the MetaFabric Architecture 2.0 lab, we assigned
each VNI a separate multicast group for simplicity.
Overlay Architecture
The term “underlay” refers to the physical networking
equipment; in this case, it is the Virtual Chassis Fabric. The term
“overlay” refers to any virtual networks created by VMware
NSX. Virtual networks are created with a MAC-over-IP encapsulation
called VXLAN. This encapsulation allows two VMs on the same network
to talk to each other, even if the path between the VMs needs to be
routed as shown in Figure 5.
Figure 5: Overlay Architecture
All VM-to-VM traffic is encapsulated in VXLAN and transmitted
over a routed network to the destination host. Once the destination
host receives the VXLAN encapsulated traffic, it can remove the VXLAN
header and forward the original Ethernet packet to the destination
VM. The same traffic pattern occurs when a VM talks to a bare metal
server. The exception is that the top-of-rack switch handles the VXLAN
encapsulation on behalf of the physical server, as opposed to the
hypervisor.
The advantage of VXLAN encapsulation is that it allows you to
build a network that is based on Layer 3. The most common underlay
architecture for SDN is the IP fabric. All switches communicate with
each other through a typical routing protocol such as BGP. There is
no requirement for Layer 2 protocols such as Spanning Tree Protocol
(STP).
One of the drawbacks to building an IP fabric is that it requires
more network administration. Each switch needs to be managed separately.
Another drawback is that to allow the integration of bare metal servers
with VMware NSX for vSphere, multicast is required for the integration
of VXLAN and MAC address learning. This means that in addition to
building an IP fabric with BGP, you also need to design and manage
a multicast infrastructure with Protocol Independent Multicast (PIM)
protocols.
The advantage of Virtual Chassis Fabric is that you can build
an IP fabric and multicast infrastructure without having to worry
about BGP and PIM. Because the Virtual Chassis Fabric behaves like
a single, logical switch, you simply create integrated routing and
bridging (IRB) interfaces and all traffic is automatically routed
between all networks because each network appears as a directly connected
network. To enable multicast on a Virtual Chassis Fabric, you simply
enable Internet Group Management Protocol (IGMP) on any interfaces
requiring multicast. There is no need to design and configure PIM
or any other multicast protocols.
The concept of something happening “again” seems pretty simple. But
when dealing with industry-wide transformations, it’s an important
phenomenon. The journeys our customers take will not play out over the
course of a few months or even quarters. Change of the magnitude we are
seeing with multicloud and artificial intelligence will take time.
And that means that sustained execution in pursuit of a compelling
vision is important. It means doing things right. And then doing them
right…again.
Outside and Inside
For Juniper, having world-renowned analysts validate the direction
and execution of the company matters. These teams are seeing the
difference experienced by our customers and how the company is
innovating in the market with new choices to simplify operational models
across the data center and into public clouds.
We believe that analyst assessments provide only part of the story.
If you want to get a fuller picture, you need to combine it with a view
from our customers.
We are equally proud of being recognized as a April 2019 Gartner Peer Insights Customers’ Choice for Data Center Networking. Based on real feedback from 250 customers, Juniper has a 4.7 out of 5 average rating
for that market, as of 17 July 2019. To us, this means that it isn’t
just the observations of analysts, but the experiences of practitioners
that is garnering attention.
Growth in the Enterprise
In many ways, this recognition is merely a reflection of things that
we have known at Juniper for years. Our commitment to improving
networking for enterprises has resulted in more and more customers each
year. With Juniper, enterprises are delivering the outcomes that matter
most to their businesses. Our commitment to enterprise goes well beyond
repackaging products and moving into adjacent markets. It’s a big reason
we have grown our enterprise business to more than $1.5B in 2018,
representing roughly a third of our total business.
With Contrail Enterprise Multicloud, we have purpose-built an
orchestration platform ideal for operating in the era of multicloud.
Combined with our full line of enterprise data center switches and
routers—from top-of-rack to data center edge—and our security
solutions—from micro-segmentation to threat prevention to firewall—we
have the full end-to-end solution required to service everything an
enterprise may need. Our solutions simplify operations across
heterogeneous environments, focusing on infrastructure orchestration,
automation, programmability, ease of management, visibility and
analytics.
And with our recent acquisition of the wireless visionary company,
Mist Systems, we have brought Wi-Fi and artificial intelligence into the
solution mix. The future of enterprise IT will be AI-driven and we have
complete reach from data center to wireless access. Our solutions, such
as AI-driven enterprises and SD-WAN, can improve user-experience by
simplifying on-boarding processes, ensuring business-critical
application performance and automating security across the entire
network.
Getting from Here to There
Of course, helping enterprises navigate transitions is more than just
a technology discussion. Ultimately, it requires robust services,
education, training and support.
Our vision for multicloud and AI-driven operations recognizes that
the path each enterprise will take will be somewhat unique, based on
where they start, where they want to go and the real-life constraints
that stand in between. Juniper has spent time aligning our solutions and
services around migration models and designed explicitly to support
enterprises with a vendor-neutral view of how to plan and stage these
technology transitions.
Minimally, it means we can help enterprises even where Juniper
solutions might not be the right fit. Ideally, it means we will be a
partner on the path to multicloud and AI-driven operations. Either way,
enterprise customers win.
Customers First Ultimately, everything comes
down to customers. We know that Juniper is the best choice for anyone
who cares about being multicloud-ready in order to manage their
infrastructure resources as a single, cohesive entity without being
unnecessarily boxed in.
We encourage you to check out some of our customer success stories to see for yourself.
Every company has weighty imperatives to deliver tangible results
within their digital transformation initiatives. Potential consequences -
IT is being asked by the business for many new things and that means IT
has to rethink much of why it does something and how it does it.
The Junos Genius
continuous learning platform helps you learn Juniper technologies and
prepare for Juniper certification exams on your schedule. An app for iOS
and Android devices, along with laptops and desktops, Junos Genius
provides certification preparation resources, practice exams, and
e-learning courses developed by experts in Juniper technology. Courses
cover automation, routing, switching, security, and more.
Features and Benefits
65-item practice tests written by subject matter experts
Access the platform at your convenience, anytime and anywhere
Use any device—Junos Genius runs on your smartphone, tablet, or other mobile device, as well as your desktop or laptop
Receive ongoing training opportunities as new content is regularly added
The
65-item practice tests will help you prepare for multiple associate,
specialist, and professional-level JNCP certification exams
Juniper Learning Bytes will help you to become more proficient at managing your network of Juniper hardware and software
Take
on-demand training courses (purchased separately) and receive the same
level of knowledge, skills transfer, and hands-on lab experience as you
would in a traditional classroom environment
Unlimited access to all hardware overview and deployment courses
Resume courses where you left off with no interruptions
View content offline…simply download and view when it is convenient
This article provides
self-service instructions on how to transfer a license activation key
from a defective device to an RMA replacement device. The Juniper End
User License Agreement (EULA) states that RMA license keys may be
transferred where the following criteria are met:
The defective hardware product has an active support contract
JTAC has confirmed the hardware as defective via a Technical Service Request.
The replacement device is the same series/platform as the defective device.*
*The replacement device
may be one provided by Juniper Networks or a spare of the same model
provided from a partner's/customer's stock.
Symptoms:
My Juniper product has
faced a hardware failure, and I require to transfer the software license
keys from the defective device to a replacement device.
Solution: Important Notes:
Self-service RMA license transfer is available only where a Juniper RMA has been initiated by JTAC.
There is no option for self-service license transfer for the following conditions:
Customer/Partner Self-Sparing where no Juniper RMA # has been created
If your request falls into one of these conditions, contact Customer Care.
Follow the relevant self-service instructions below for your product, which depends on whether it is running Junos or non-Junos:
Junos OS Enabled Products (e.g. SRX Series, QFX Series, Ex Series)
Note:For
MX Series, no license transfer is required following RMA. You may
continue to use the same license unlocking key or trust-based Software
'Right to Use' on your replacement product. If you have misplaced your
MX Series unlocking key or Software 'Right to Use' document, then
contact Customer Care with your Purchase Order details.
Step 1: Gather the RMA number and device serial numbers:
RMA Number (e.g. R299218954)
Defective Device Serial Number
Replacement Device Serial Number*
Tip: This information is located via the Technical Service Request or the RMA's module in MyJuniper Service Request Manager (MYJ-SRM).
*The
Replacement Device Serial Number may be one provided by Juniper
Networks or a product of the same model provided from either a Juniper
Partner or spare stock. When deploying your own spare, please ensure
that you contact Customer Care so that support entitlement and product registration information may also be updated!
Step 2: Activate the replacement licenses using the RMA Tool:
Non-Junos OS Products (e.g. SSG Series, JSA Series, Junos Space)
Note: As specified in the important note above, for RMA
license key transfer on Juniper Advanced Threat Protection (JATP
Series), contact Customer Care.
Step 1: Gather the RMA number and Device Serial Numbers:
RMA Number (e.g. R299218954)
Defective Device Serial Number
Replacement Device Serial Number*
* The
Replacement Device Serial Number may be one provided by Juniper
Networks or a product of the same model provided from either a Juniper
Partner or spare stock. When deploying your own spare, please ensure
that you contact Customer Care so that support entitlement and product registration information may also be updated!
Step 2: Generate replacement licenses using the RMA Tool.
Hybrid and multi-cloud are
increasingly common deployment models, which makes integration a
priority. Review three specific approaches to connect on-premises and
cloud-based systems.
The reality is: Many multi-cloud environments still include some
on-premises components. These include OSes, databases and application
servers that both vendors and IT teams have retooled for years to reach
out to public cloud. But, though they are starting to improve,
public cloud providers haven't traditionally done a great job ensuring
their technology can reach back into on-premises systems. Enterprises,
as a result, struggle to provide core integrations between on-premises
and cloud systems.
Here are three integration approaches admins can take to effectively
fold their on-premises resources into multi-cloud environments.
Data integration
Data integration -- the most straightforward of the three approaches
outlined here -- refers to the movement of data from on-premises
applications and data stores to their analogs in the public cloud. There
are numerous on-premises and cloud-hosted data integration tools, such
as Dell Boomi, SnapLogic and MuleSoft, from which enterprises can
choose. These tools are sometimes referred to as integration PaaS.
Enterprises need an interface that exists between the data
integration server and the on-premises and public cloud-based systems
being integrated. These are typically APIs that can interface with ERP
systems, databases and other custom or proprietary resources. Data is
consumed from the source system, either on premises or in the cloud, and
then sent to the data integration server, where it's transformed and
then sent to the target system.
Security integration
Security integration
is the ultimate objective for enterprises in multi-cloud environments.
IT teams want a single security layer that can work across on-premises
and public cloud platforms, which typically means they need a single and
centralized directory system, such as Active Directory or other LDAP-compliant options.
These shared directories are the jumping off point for an identity and access management (IAM)
strategy that works well across on-premises and cloud-based systems.
Once an IAM tool verifies a user's identity, it authenticates that user
for most resources across a hybrid or multi-cloud environment, without
the need to reauthenticate for each individual database or application.
Admins can set up roles for users and themselves, as well as provide and
control access to local and cloud-based resources through customizable
configurations based on their specific security needs.
Service integration
Service integration is perhaps the least known on this list. It deals with specific APIs, services or microservices
that enable systems to share both behavioral information and data. It's
not enough to just stand up these services, though; enterprises need to
secure, govern and track them across multi-cloud environments. To do
this, use API managers and service repositories to enable the discovery
of services and also enforce policies that dictate how those services
are used.
Service integration is joined at the hip with server integration and
service orchestration tools. These tools help developers bind services
together to create more complex processes or applications. For instance,
an application that cleans up data once a month would call upon several
other services, such as those for data security, verification and
validation, to complete that task.
