Sunday, 1 May 2022

Understanding the Junos Space SDK

 

The Junos Space SDK provides a means for developing end-user specific applications that accesses the capabilities and resources provided by the Junos Space Platform environment. Implementation exposes Junos Space Platform resources through a Web-based (HTTP) interface using Representational State Transfer (REST) APIs. Developers can browse the existing REST Web services using a customized HTTP-enabled client application. Under this environment, a Web browser client application or a standalone client application can make HTTP requests to access related information, which is available to the Junos Space Platform.

The Junos Space SDK also provides a mechanism for application developers to expose their own Web services as RESTful APIs.

REST Design

The Junos Space SDK development system implements the REST architectural style to accomplish its goals:

  • Representational State Transfer (REST) is a concept that employs the Web's stateless client-server model. It represents REST Web services as resources identified by URLs.

    Resources can be added, modified, or deleted using the CRUD APIs. Resources can also expose their own method links, which, when accessed, perform a certain action on the resource. (Source: RESTful Web Services.)

    In REST, requests and responses are built around the transfer of "representations" of "resources". A resource can be any object that can be addressed. A representation of a resource is typically an XML or JSON document that captures the current or intended state of a resource. (Source: http://en.wikipedia.org/wiki/Representational_State_Transfer.)

  • Hypermedia As The Engine Of Application State (HATEOAS) is a constraint on REST that says that a client of a REST application must only know a single fixed URL to access it. Any and all resources should be discoverable dynamically from that URL, through hyperlinks included in the representations of returned resources.

SDK Elements

The Junos Space SDK Toolkit helps in the development of Junos Space applications. These applications can then be deployed on the Junos Space Platform. The SDK Toolkit comes pre-loaded with the Junos Space Virtual Appliance (JSVA), which can be used to emulate the Junos Space Platform for functional verification of the developed application.

Note: All applications must be signed with a certificate (issued by Juniper Networks) to be deployed into production environments, but they do not require a certificate when deployed on the JSVA.

The Junos Space SDK development system consists of these components:

  1. Development Tools

    • The Junos Space Eclipse plug-in installed on an Eclipse IDE.

    • The Junos Space Eclipse plug-in allows wizard-based creation of different types of Junos Space applications, automated build, and deployment of applications for test and debug purposes, control of device simulations on a device simulator, and other features.

  2. REST Web Services interfaces
    • Interfaces to the core capabilities of the Junos Space platform. These REST Web Service interfaces are a part of the Junos Space network application platform.

  3. Device and environment simulators

    • The development environment includes the Junos Space Virtual Appliance that provides access to:

      • A fully functional instance of the Junos Space network application for use in deploying and testing applications developed using the Junos Space SDK.

      • Device and element simulators providing the ability to test applications against virtual Juniper Network devices.

  4. Performance, Analytics, Security, and Profiling tools

    • While the Junos Space SDK does not ship performance, analytics, security, or profiling tools, it is compatible with the most popular tools available today, such as VisualVM, JBoss Tools, and so on.

  5. Reference Apps

    • Reference applications, including annotated source code. These applications provide examples for developers to learn from and use.

  6. Documentation and Online Resources

    • The SDK install package includes complete documentation for using the SDK, including an Installation Guide, an API Reference, and an Application Developer Guide. The latter two are provided in the Eclipse plug-in as online help. Finally, the SDK includes reference applications demonstrating how to use the many SDK features.

From the SDK user's perspective, the SDK Web development environment looks like the following:

Wednesday, 13 April 2022

Junos Space SDK

 

The Junos Space SDK delivers on the programmability promise of software-defined networking (SDN) by making it easy to create custom analytic and management applications that run on the Junos Space Network Management Platform. The connections and intelligence embedded in the network can be leveraged to create customized management solutions that meet specific needs and to create new revenue streams.

The Junos Space SDK also makes it simple to safely extract data from your network to add intelligence to existing applications and new solutions you create. In this way, you can enable automated responses to application and network conditions that improve the user experience.

Key Features


  • Real-time policy management 
  • Energy usage tracking 
  • Custom workflows 
  • Network insight for business intelligence 
  • Correlation of user subscribed services
  • Policy and QoS management

Features + Benefits

Flexible Applications Based on Behavior

Create better user experiences with networks and applications that make real-time changes based on behavior.

Enhanced Network Visibility and Control

Gain visibility into network activity and control outcomes using apps tailored for your specific analytic and management needs.

Better Access to Network Information

Access network data through the Application-Layer Traffic Optimization (ALTO) protocol, BGP-TE, GenApp interface, and other tools.

Enhanced End-User Experience

Deliver better quality of service and experiences to your customers.

Advanced Orchestration

Improve cost-effectiveness, resource optimization, and personalization of services.

New Revenue Opportunities

Discover new offerings likely to appeal to subscribers based on the data you collect about their habits, buying history, and preferences.

Wednesday, 23 March 2022

Reimagining Data Center Operations with Intent-Based Networking: The Latest Step in an Innovative Apstra Journey

 

New Apstra product enhancements make it easier than ever to experience the benefits of a Juniper experience-first data center

It’s been a little over a year since Juniper Networks took the bold step of acquiring Apstra, the creator of the only vendor-agnostic intent-based networking software for data center operations. In that time, much has happened both externally and internally at Juniper, all of which has enabled the company’s data center business to continue its growth. Many factors contributed to this tremendous success, including continued investment in the Juniper Apstra product, development of Apstra partners and significant Apstra customer momentum across both the enterprise and service provider segments.

Today, we’re excited to announce the latest series of Apstra product enhancements that will enable Juniper to continue its strong data center momentum into 2022 and beyond. Not only have we expanded all the benefits of our intent-based networking solution to more data center environments, but it’s even easier to deploy and operate with more robust security capabilities.

To the Edge and Beyond

No one could have predicted the surge in workload distribution that a pandemic would generate – including data volume and demand for faster, more reliable service. To support increasing business digitization and reduce latency, many organizations have turned to edge computing to bring data processing closer to the end user.

Now, in addition to using Apstra in centralized or hyperscale data centers, customers can use our powerful software in edge locations – or at any remote site that doesn’t require the full scale of a multistage switching network. With Apstra, networking teams can centrally design, deploy and operate a network consisting of an EVPN-VXLAN overlay with an IP fabric underlay in a configuration made up of only two leaf switches. Additionally, teams can scale and add access switches to the fabric whenever needed. Apstra will automatically register the new devices and apply the pre-validated configurations.

Zero Trust for a More Secure Data Center

Apstra’s single source of truth is a key foundation for Zero Trust security, enabling network operators and security experts to view the exact state of the network, its configuration and the intended outcome. Apstra’s enhanced policy assurance introduces new segmentation capabilities. By allowing organizations to apply all their security policies from a single point and to specify enforcement at the most granular level, Apstra ensures that the network is continuously compliant, consistent and reliable.

Apstra also provides:

  • Role-Based Access Control (RBAC) to limit who can see which data
  • Continuous validation against intent to identify configuration drift in real time
  • Policy assurance to confirm that security policies are being enforced as intended
  • Live audits to track the origin of changes

Improvements in RBAC, audit and security policy granularity have all been made to meet the requirements of customers using Apstra in multi-tenant environments.

Hassle-Free Deployments and Migrations

With IT requirements evolving at an unprecedented rate, constant data center deployments and migrations are inevitable. In addition, the number of data centers in use frequently changes, either increasing due to natural IT growth or acquisitions, or decreasing when older data centers are decommissioned or businesses divest themselves of certain IT requirements or applications. These deployments and migrations can be challenging, expensive and resource intensive. But they don’t have to be.

Juniper’s new Apstra Deployment and Migration services leverage Apstra’s intent-based networking architecture and in-house tools to help organizations significantly reduce the time, cost and risk associated with deployments. Our experts perform real-time preconditioned validations based on the exact blueprint, network models and operating systems. This enables customers to migrate to the latest architectures and automate everyday operations with minimal downtime and an unprecedented level of assurance, while also reducing the CapEx and OpEx associated with physical and virtual testing during deployment. Customers can also take advantage of best-practice design methodologies and in-house automation tools to accelerate deployments for increased business agility.

New Data Center Learning

Both experienced and new data center networkers will have the ability to advance their careers with Juniper’s revised curriculum that includes new and updated training and certifications.

  • Introduction to Juniper Data Center Networking: This foundational course provides introductory instruction on data center switching using Juniper products and covers the baseline knowledge necessary to understand a data center that’s built upon an IP fabric with an EVPN/VXLAN overlay. This is the recommended preparation for the new Juniper Networks Certified Associate, Data Center (JNCIA-DC) certification, which launches in May 2022.
  • Data Center Automation using Juniper Apstra: This expanded course provides the necessary knowledge required to manage data center networks with Apstra and now covers how to add a spine, leaf and generic system to a running blueprint (IP fabric), VMware integration and data center interconnect. It’s recommended as preparation for the new Juniper Networks Certified Specialist, Data Center (JNCIS-DC) certification, also launching in May 2022.
  • Data Center Fabric with EVPN and VXLAN: This recently updated course now includes coverage of enhanced loop protection, MAC-VRF, ERB, collapsed fabric configuration, super spine configuration, EVPN multicast-assisted replication, filter-based forwarding in the data center and seamless EVPN-VXL. This course is recommended training for the updated Juniper Networks Certified Professional, Data Center (JNCIP-DC)

A Year of Integration, Innovation and Achievements

Now that we’ve described the latest enhancements, let’s look back at how far Juniper has come with Apstra since the acquisition last year.

  • Apstra was integrated with more Juniper products. It takes time to fully integrate a newly acquired company, but Juniper hit the ground running this past year! We’ve added Apstra support for more Juniper switches and routers, as well as for all current versions of our Junos® operating system, including Junos Evolved in spine, super-spine and non-EVPN-VXLAN leafs.
  • Apstra adoption grew by leaps and bounds. Since the acquisition, Apstra logos have increased over 400 percent. Additionally, pre-acquisition customers renewed their Apstra licenses. For example, one Fortune 5 customer not only renewed, but also deployed Apstra to a second data center and introduced Apstra to a major managed services provider.
    • Juniper expanded Apstra’s multivendor support. Apstra is the only intent-based networking software that eliminates vendor lock-in, and Juniper proved that it was committed to keeping this unique feature. For example, in last year’s Apstra 4.0 release, we provided validated qualification for Cisco Systems, Arista Networks, Dell Technologies and added VMware NSX-T 3.0 and Enterprise SONiC integrations. Although we believe that customers benefit most by combining Apstra with our own QFX Series switches and other proprietary hardware and software, our primary goal is to give customers the tools they need to reduce operational complexity and assure reliability – regardless of which vendor environment they have.

    Tuesday, 1 February 2022

    2022-01 Security Bulletin: Junos OS and Junos OS Evolved: After receiving a specific number of crafted packets snmpd will segmentation fault (SIGSEGV) requiring a manual restart. (CVE-2022-22177)

     Product Affected:

    This issue affects Junos OS 12.3, 15.1, 18.3, 18.4, 19.1, 19.2, 19.3, 19.4, 20.1, 20.2, 20.3, 20.4, 21.1, 21.2. This issue affects any Junos OS Evolved releases prior to 21.2R3-EVO, 21.3.
    Problem:
    A release of illegal memory vulnerability in the snmpd daemon of Juniper Networks Junos OS, Junos OS Evolved allows an attacker to halt the snmpd daemon causing a sustained Denial of Service (DoS) to the service until it is manually restarted.

    This issue impacts any version of SNMP – v1,v2, v3

    This issue affects:
    Juniper Networks Junos OS
    • 12.3 versions prior to 12.3R12-S20;
    • 15.1 versions prior to 15.1R7-S11;
    • 18.3 versions prior to 18.3R3-S6;
    • 18.4 versions prior to 18.4R2-S9, 18.4R3-S10;
    • 19.1 versions prior to 19.1R2-S3, 19.1R3-S7;
    • 19.2 versions prior to 19.2R1-S8, 19.2R3-S4;
    • 19.3 versions prior to 19.3R3-S4;
    • 19.4 versions prior to 19.4R2-S5, 19.4R3-S6;
    • 20.1 versions prior to 20.1R3-S2;
    • 20.2 versions prior to 20.2R3-S3;
    • 20.3 versions prior to 20.3R3-S1;
    • 20.4 versions prior to 20.4R3;
    • 21.1 versions prior to 21.1R2-S2, 21.1R3;
    • 21.2 versions prior to 21.2R1-S2, 21.2R2.
    Juniper Networks Junos OS Evolved
    • 21.2 versions prior to 21.2R3-EVO;
    • 21.3 versions prior to 21.3R2-EVO.
    The following minimal configuration is needed:
    [snmp community 'community-name"] using a Read Write (RW) Community

    Read Only (RO) communities are not impacted by this issue.

    Juniper SIRT is not aware of any malicious exploitation of this vulnerability.

    This issue was discovered during external security research.

    This issue has been assigned CVE-2022-22177.

    Solution:

    The following software releases have been updated to resolve this specific issue:

    Junos OS: 12.3R12-S20, 15.1R7-S11, 18.3R3-S6, 18.4R2-S9, 18.4R3-S10, 19.1R2-S3, 19.1R3-S7, 19.2R1-S8, 19.2R3-S4, 19.3R3-S4, 19.4R2-S5, 19.4R3-S6, 20.1R3-S2, 20.2R3-S3, 20.3R3-S1, 20.4R3, 21.1R2-S2, 21.1R3, 21.2R1-S2, 21.2R2, 21.3R1, and all subsequent releases.

    Junos OS Evolved: 21.2R3-EVO, 21.3R2-EVO, 21.4R1-EVO, and all subsequent releases.

    This issue is being tracked as 1613874.

    Workaround:

    There are no workarounds for this issue.

    For V1, V2 you can reduce the risk of exploitation by configuring the client-list to limit access to network management system (NMS) machines.

    See the Network Management and Monitoring Guide for further instructions.

    example:

    [snmp client-list client-list-name "ip-addresses";]

    For V3 you can reduce the risk of exploitation by configuring SNMP security to trusted devices only.

    For any release of SNMP you can reduce the risk of exploitation by implementing source and destination IP filter rules as well as using Read Only communities where possible.

    Regardless of these risk reduction methods, an attacker able to spoof trusted IP addresses can send the attack to an exposed and reachable SNMP RW community.

    Implementation:
    Software releases or updates are available for download at https://support.juniper.net/support/downloads/.

    Sunday, 2 January 2022

    JUNOS Getting Started - Route-based vs Policy-based VPN

     Route-based vs Policy-based VPN

    With policy-based VPN tunnels, a tunnel is treated as an object that together with source, destination, application, and action, comprises a tunnel policy that permits VPN traffic. In a policy-based VPN configuration, a tunnel policy specifically references a VPN tunnel by name.

    With route-based VPNs, a policy does not specifically reference a VPN tunnel. Instead, the policy references a destination address. When the security device does a route lookup to find the interface through which it must send traffic to reach that address, it finds a route via a secure tunnel (ST) interface, which is bound to a specific VPN tunnel.

    Thus, with a policy-based VPN tunnel, you can consider a tunnel as an element in the construction of a policy. With a route-based VPN tunnel, you can consider a tunnel as a means for delivering traffic, and the policy as a method for either permitting or denying the delivery of that traffic.

     

    The following are reasons to implement route-based VPN:
    • Source or destination NAT (NAT-src or NAT-dst) needs to occur as traffic travels through the VPN.
    • There are overlapping subnets or IP addresses between the two LANs.
    • Hub-and-spoke VPN topology is used in the network.
    • Primary and backup VPN are required.
    • A dynamic routing protocol (for example, OSPF, RIP, or BGP) is running across the VPN.
    • Multiple subnets or networks at the remote site across the VPN need to be accessed.

    The following are reasons to implement policy-based VPN:

    • The remote VPN device is a non-Juniper device.
    • Only one subnet or one network at the remote site across the VPN needs to be accessed.

    Wednesday, 1 December 2021

    Junos following products are vulnerable to the issue described in CVE-2021-44228

    • Juniper Networks BTI proNX Service Manager Software
    • Juniper Networks JSA Series User Behavior Analytics prior to version 4.1.14 see https://www.ibm.com/support/pages/node/6526640 for further details.
    • Juniper Networks Junos Space Network Management Platform when OpenNMS has been enabled.
    • Juniper Networks NorthStar Controller / NorthStar Planner
    • Juniper Networks Paragon Pathfinder
      • 21 version 21.1, 21.2 and later versions.
    • Juniper Networks Paragon Planner
      • 21 version 21.1, 21.2 and later versions.

    Monday, 1 November 2021

    Junos : request chassis cluster failover redundancy-group

     Syntax

    content_copy zoom_out_map
    request chassis cluster failover node node-number redundancy-group redundancy-group-number
    

    Description

    For chassis cluster configurations, initiate manual failover in a redundancy group from one node to the other, which becomes the primary node, and automatically reset the priority of the group to 255. The failover stays in effect until the new primary node becomes unavailable, the threshold of the redundancy group reaches 0, or you use the request chassis cluster failover reset command.

    After a manual failover, you must use the request chassis cluster failover reset command before initiating another failover.

    Options

    • node node-number—Number of the chassis cluster node to which the redundancy group fails over.

    • Range: 0 or 1

    • redundancy-group group-number—Number of the redundancy group on which to initiate manual failover. Redundancy group 0 is a special group consisting of the two Routing Engines in the chassis cluster.

      Range: 0 through 255

    Required Privilege Level

    maintenance

    loading...