Category Archives: Monitoring

Service Assurance with Juniper Paragon Active Assurance (Netrounds)

Automation, Juniper, Junos, Monitoring, Networking, NFV, SDN, , , ,

Hi All, hope you all are well.

In this blog, will look at Juniper’s recent acquisition called Netrounds. Netrounds have been rebranded as Paragon Active Assurance (PAA) which is part of Paragon Automation portfolio and is a programmable, active test and monitoring solution for physical, hybrid, and virtual networks. Unlike passive monitoring approaches, Paragon Active Assurance uses active, synthetic traffic to verify application and service performance at the time of service delivery and throughout the life of the service.

There are various features of PAA however in nutshell, operations teams can use PAA to identify, understand, troubleshoot, and resolve issues before your end users even notice them. This service performance visibility can help decrease incident resolution time by as much as 50%, resulting in greater end-user satisfaction and retention.

We will be using simple topology consisting of a Controller, Test Agents and 2 vMXs to model it in EVE-NG.

eve-ng netrounds juniper active assurance
EVE-NG Topology

Controller has been instantiated by spinning clean Ubuntu 18.04.05 LTS VM and then added the required controller packages.
 
You can get the Controller up and running by following the below URL:
 
https://www.juniper.net/documentation/us/en/software/active-assurance3.0.0/paa-install/topics/concept/install-os-software.html
 
Controller Version: 3.0.0
vMX version: 18.2R2-S4
Test Agent: 3.0.0.23

Once the controller is up and running and has been licensed, you can open the UI page on the its management address.

In my case its on https://192.168.8.113/ and you will be presented with login screen where after getting authenticated, you will land on Dashboard page.

For us, as expected nothing is here as no configuration has been added via UI.

Once controllers are up, we will add Test Agents (TA) to manage all from single pane of glass.

We will add 2 TAs, and for that we need to build new Linux VM however this time its all prepackaged VM in .qcow2 format which we can download from Controller UI.

Download the .qcow2 format, disk image.

Once downloaded, we will boot the VM using this Qemu image and will get the Test Agent up and running. Now we need to open console to TEST Agent and add the Controller IP in format: <controller-ip>:6000

6000 is important as TA and Controller talk on this port. If you have firewall in between, make sure to allow this port.

Once both TAs are added, they will be shown in the Test Agents Section on the left menu of the Controller as below.

Click on each Test Agent and configure the IP Addresses on Revenue port. In my case its eth1 which is connected to vMXs.

Before we delve more into TAs, let me give you run down of vMXs.

vMXs have OSPF, LDP, RSVP, BGP, running between them. I have configured L2VPN CCC between 2 VMXs.

As you can see below, interface towards TA1 is in vlan 601 and hence we need to accordingly add 601 vlan on TA1 and assign the IP. In my case, I have defined 20.20.20.1/24.

root@vMX-1> show mpls lsp
Ingress LSP: 1 sessions
To From State Rt P ActivePath LSPname
2.2.2.2 1.1.1.1 Up 0 * vmx1-to-vmx2
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
1.1.1.1 2.2.2.2 Up 0 1 FF 299808 - vmx2-to-vmx1
Total 1 displayed, Up 1, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

root@vMX-1> show connections
CCC and TCC connections [Link Monitoring On]
Legend for status (St): Legend for connection types:
UN -- uninitialized if-sw: interface switching
NP -- not present rmt-if: remote interface switching
WE -- wrong encapsulation lsp-sw: LSP switching
DS -- disabled tx-p2mp-sw: transmit P2MP switching
Dn -- down rx-p2mp-sw: receive P2MP switching
-> -- only outbound conn is up Legend for circuit types:
<- -- only inbound conn is up intf -- interface
Up -- operational oif -- outgoing interface
RmtDn -- remote CCC down tlsp -- transmit LSP
Restart -- restarting rlsp -- receive LSP

Connection/Circuit Type St Time last up # Up trans
l2vpn-1 rmt-if Up Mar 5 13:02:14 2
ge-0/0/1.601 intf Up
vmx1-to-vmx2 tlsp Up
vmx2-to-vmx1 rlsp Up

Another important consideration to make is NTP. Make sure NTP is synced properly on TAs before running the test. You can use any NTP server for this or make your controller as NTP server.

That’s all for vMXs, let me know if you have any particular query on it. We will look at TAs now.

To start the test, Click on ‘New Monitor’ under Monitoring option on left hand menu.

Fill the details and select Element. In our case we have selected 2 Elements, UDP and VOIP UDP which are basically 2 different streams with 2 different profiles going at same time.

Configure each element separately with parameters and Client and Server interface ports.

You can define the threshholds here and frame rates, dscp value of streams.

Press the start button. Once started, we can verify the traffic on vMXs in both Input and Output direction below which suggests that bidirectional traffic is working.


root@vMX-1> show interfaces ge-0/0/1 | match rate | refresh 1

---(refreshed at 2021-03-05 13:22:05 UTC)---

  Input rate     : 185792 bps (59 pps)

  Output rate    : 185792 bps (59 pps)

    FEC Corrected Errors Rate               0

    FEC Uncorrected Errors Rate             0

---(refreshed at 2021-03-05 13:22:06 UTC)---

  Input rate     : 185792 bps (59 pps)

  Output rate    : 185792 bps (59 pps)

    FEC Corrected Errors Rate               0

    FEC Uncorrected Errors Rate             0

---(refreshed at 2021-03-05 13:22:07 UTC)---

  Input rate     : 188064 bps (59 pps)

  Output rate    : 188064 bps (59 pps)

    FEC Corrected Errors Rate               0

    FEC Uncorrected Errors Rate             0

---(refreshed at 2021-03-05 13:22:08 UTC)---

  Input rate     : 188064 bps (59 pps)

  Output rate    : 188064 bps (59 pps)

    FEC Corrected Errors Rate               0

    FEC Uncorrected Errors Rate             0

---(refreshed at 2021-03-05 13:22:09 UTC)---

  Input rate     : 187680 bps (59 pps)

  Output rate    : 187680 bps (59 pps)

    FEC Corrected Errors Rate               0

    FEC Uncorrected Errors Rate             0

---(refreshed at 2021-03-05 13:22:10 UTC)---

  Input rate     : 187680 bps (59 pps)

  Output rate    : 187680 bps (59 pps)

    FEC Corrected Errors Rate               0

    FEC Uncorrected Errors Rate             0

---(refreshed at 2021-03-05 13:22:11 UTC)---

Once stopped. Click on the report at the top and you will get the status of test along with results and graphs.

That’s all from this blog. Its just an introduction to PAA however its capable of doing much much more. We can use the RPM/TWAMP on Routers to get the 2 way or Round trip time measurements from the network which can give you edge before handing over the network to your customers for actual traffic and proactively troubleshoot for any issues.

That’s all for this. I will add more test in next blogs, however till then let me know if you have any queries.

Mohit

Advertisement

Juniper Northstar SDN Controller – Part 2

Automation, Juniper, Junos, Monitoring, MPLS, Networking, NFV, RSVP, SDN, , , , , , , , ,

Following on my earlier blog on Northstar here: https://networkzblogger.com/2017/03/17/juniper-northstar-wan-sdn-controller, recently I got chance to work on next release of it which has among other things is ability to initiate P2MP (Point to Multipoint) LSPs. P2MPs are big use case in Media and Broadcast network and ability to create them via controller would be too helpful. However there is a catch. As discussed in my earlier blog, the NorthStar (NS) Controller relies on PCEP (Path Computation Element Protocol) to deploy a path between the PCC router and PCE (Controller). Currently P2MPs are not initiated by PCEP or its standard is not ratified. So Juniper have come up with another way of configuring it and that’s via Netconf. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple Remote Procedure Call (RPC) layer. The protocol messages are exchanged on top of a secure transport protocol like SSH etc.

In this blog, instead of looking at PCEP based LSPs from Northstar we will explore netconf functionality and what other features have been introduced in new ns version.

Below is our current model which is built using TED (Traffic Engineering Database) by Northstar and if you look closely there are 2 devices which have PCEP session up because they have correct Junos code on it (15.1F6 and later) however all others are having netconf session Up even if they are on Junos 10, 12, 14 etc. which is cool thing. So as long as you have netconf stanza added in Junos config and have ssh connectivity that is all Northstar need to connect to devices.

Pic-1

Lets start by configuring a P2MP LSP via Northstar

You can see 2 options here for provisioning method. One is PCEP and other is Netconf.

Pic-2

We will choose Netconf and fill other bits.

Pic-3

We have kept Path as dynamic however we can choose required path to TE it more. Under Advanced Tab, you will see P2MP Name field, in which we have added the P2MP name.

Pic-4

All others field you can pretty much keep default.

Once you submit it, Northstar will open a netconf session on port 830 towards headend router which is M320 in our case and push and commit the config to it.

Pic-5

You can see above LSP has become Active and its showing the path as well which this LSP is taking. Now one of the biggest difference between PCEP created LSP and one created from Netconf is that Netconf LSPs will be part of startup-config in Junos as the configs are committing to it so it can be slow process getting your LSP up based upon commit time. Also all Netconf created LSPs are basically shown as PCC Controlled. However PCEP just sent LSP state to network to build E2E path rather than config. PCEP LSP config still resides in NS database and LSPs are created within seconds and are PCE Initiated.

M320> show configuration protocols mpls label-switched-path demo-0610
from 10.198.123.203;
to 10.198.123.103;
p2mp demo-0610-p2p;
primary demo-0610.p0 {
 apply-groups demo-0610-p2p;
}

M320> show configuration groups demo-0610-p2p
protocols {
 mpls {
 label-switched-path <*> {
 primary <*> {
 bandwidth 10m;
 priority 7 7;
 }
 }
 }
}

Ok so that’s for P2MP LSPs which is clean. In 3.1.0 one of the issue we found was related to commit process. Suppose you have 10 LSPs to be created from one source to destination. With Netconf, NS will commit 10 times individually for those LSPs which can be time consuming on some of the MX104s, MX80s with less CPU power. Juniper is looking to change this and putting the commit in batches to decrease the overall time and commit process which would be excellent J

So we have seen now how P2MP LSPs are created via Netconf however we haven’t seen how Netconf parameters are configured on NS as with netconf you can see the analytics data as well which is populated by Telemetry. We will see Telemetry in some other blog.

Under Administration -> Device Profiles we have to set the parameters for individual device.

Pic-6

We enable Netconf and add login details and password. You can test the connectivity as well from NS before actually trying to provision the network.

Pic-7

Apart from P2MP, another thing which has been introduced is while provisioning the LSP you can select which routing method you need to choose. There are many methods starting from default to routebyPCC, etc. default means that NS will calculate the path and routebyPCC means routers will calculate the path and NS won’t be having any say in it.

Pic-8

Another new feature which has been introduced in release 3.1.0 is setting the current path as explicit.

So above P2MP LSP I created was just dynamic however if we want to explicitly make this path as Strict so that LSP doesn’t change path based upon the network conditions we can configure it as below.

Pic-9

If we see the CLI now, NS has filled strict path in it.

M320> show configuration protocols mpls path demo-0610.p0
10.177.177.5 strict;
10.0.0.245 strict;

Ok that’s all for this blog. I hope you like it and let me know your views if you are looking at using NS for your network and if you are already, what are your use cases J

 

R

Mohit Mittal

 

Junos Telemetry

Cisco, Juniper, Junos, Monitoring, Networking, SDN, SNMP, , , , , , ,

Hi All

Recently I attended a Juniper workshop in their London office and heard about Junos Telemetry concept which was really a new one for me and I quite liked it.

The basic idea is to replace traditional methods of collecting the data from devices on Management stations which helps Operations teams in more automated solution for managing their vast networks.

Traditional method which I am talking about here is SNMP which works on Pull model where Management station polls the network devices to gather useful information using MIBs and in turn displays the data to Network Admins/Operations Team. This method is being used currently and have succeed a lot. However as Hardware vendors are providing more and more APIs in their products which can be used by users to configure their devices in lots of innovative ways, polling or gather statistics via SNMP is not scalable in those scenario. Also SNMP polls the devices at regular interval which is again an operational challenge as something can happen on device between the intervals which wont be captured.

Junos Telemetry or Telemetry concept in general provides a Push model where we can configure the device to send the real time data based upon any trigger or in general for various parameters. 

Telemetry

  Source: Juniper Networks

In this blog, we are not going to see how its configured in CLI but who knows when I can get hold of appropriate Junos code and have a play on it 🙂 but till then let’s see what are its other features.

Junos Telemetry interface (JIT) as I mentioned above works on Push model where it streams the results to collector or even to Controller like Northstar to drive MPLS LSPs. Format of data what is being sent is either in form of Google Protocol buffer GPB or can be JSON based.

Juniper provides the collector software however there are open source collectors as well called OpenNTI collector which is basically a docker container consisting of 3 open-source components.

Shown below is one of the Visualization chart using Grafana,

Graphna

From application point of view, i think its one of the application could be to re-route the LSPs or create a LSP from Northstar Controller based upon the bandwidth statistics from interface. Once interface statistics reported to collector exceeds certain threshholds, Application can instruct Northstar controller to create a LSP via other route which can in long term works towards Self Driving Networks.

Other Application could be to provide more user-friendly stats about routers/network device to Operations like Memory, CPU usage in environment where thousands of routes or control packets are going via routers and memory hog can be created because of this.

Junos Telemetry Interface was introduced in Junos OS Release 15.1F3, on MX Series routers with interfaces configured on MPC1 through MPC6E, and on PTX Series routers with interfaces configured on FPC3.

So that’s all for Telemetry. I haven’t added much details on this as this is really a new concept for me and as n when I read more about it or get a chance to do hand-on on it, I will write more. Let me know your views on it and if you have used or planning to use this in your network.

Regards

Mohit

 

How to find SNMP OID in JunOS

Juniper, Monitoring, Networking, SNMP, ,

Before we got into that, lets see what is SNMP?

Simple Network Management Protocol (SNMP) is an application–layer protocol for exchanging management information between network devices. It is a part of Transmission Control Protocol⁄Internet Protocol (TCP⁄IP) protocol suite.

SNMP is one of the widely accepted protocols to manage and monitor network elements. Most of the professional–grade network elements come with bundled SNMP agent. These agents have to be enabled and configured to communicate with the network management system (NMS).

SNMP consists of

SNMP Manager:

A manager or management system is a separate entity that is responsible to communicate with the SNMP agent implemented network devices. This is typically a computer that is used to run one or more network management systems.

Managed Devices:

A managed device or the network element is a part of the network that requires some form of monitoring and management e.g. routers, switches, servers, workstations, printers, UPSs, etc…

SNMP Agent:

The agent is a program that is packaged within the network element. Enabling the agent allows it to collect the management information database from the device locally and makes it available to the SNMP manager, when it is queried for. These agents could be standard (e.g. Net-SNMP) or specific to a vendor (e.g. HP insight agent)

Every SNMP agent maintains an information database describing the managed device parameters. The SNMP manager uses this database to request the agent for specific information and further translates the information as needed for the Network Management System (NMS). This commonly shared database between the Agent and the Manager is called Management Information Base (MIB).

In other words, MIB files are the set of questions that a SNMP Manager can ask the agent. Agent collects these data locally and stores it, as defined in the MIB. So, the SNMP Manager should be aware of these standard and private questions for every type of agent.

Management Information Base (MIB) is a collection of Information for managing network element. The MIBs comprises of managed objects identified by the name Object Identifier (Object ID or OID).

A typical object ID will be a dotted list of integers. For example, the OID in RFC1213 for “sysDescr” is .1.3.6.1.2.1.1.1

SNMP

Now the real question…how to find the SNMP OID corresponds to SNMP Object name in Junos?

For that firstly, we need to find the exact object name

Lets say we have to check the OID corresponding to BGP AS, in this we can either give the command as following:

show snmp mib walk 1 | match bgp

This will be give us number of results however if we already know the object name then we can match that specific name. Currently I don’t know so I just mentioned bgp and it gave me lots of output.

RE-1> show snmp mib walk 1 | match bgp

bgpVersion.0 = 10

bgpLocalAs.0 = 65004

bgpPeerIdentifier.10.0.0.241 = 0.0.0.0

bgpPeerIdentifier.10.10.10.10 = 0.0.0.0

bgpPeerIdentifier.10.10.10.14 = 0.0.0.0

bgpPeerIdentifier.10.10.10.18 = 0.0.0.0

bgpPeerIdentifier.10.30.205.2 = 0.0.0.0

bgpPeerIdentifier.10.30.205.6 = 0.0.0.0

.

.

.

I can see one of the output is bgpLocalAs.0 which is I am after, so lets see how we can get the OID corresponding to it.

RE-1> show snmp mib walk bgpLocalAs | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/15.1F6/junos">
    <snmp-object-information xmlns="http://xml.juniper.net/junos/15.1F6/junos-snmp">
        <snmp-object>
            <name>bgpLocalAs.0</name>
            <object-value-type>number</object-value-type>
            <object-value>65004</object-value>
            <oid>1.3.6.1.2.1.15.2.0</oid>
        </snmp-object>
    </snmp-object-information>
    <cli>
        <banner></banner>
    </cli>
</rpc-reply>

Here it is , so we got the OID and you can use this OID in NMS systems to poll this specific object.

Regards

Mohit

Netflow!!

Cisco, Juniper, Monitoring, Networking, , , ,

Service providers these days are continuously facing a challenge and that challenge is someone intruding their network…Suspicious access from unknows IPs, hacking etc.. put pressure on service provider’s environment, their customer’s network and put a dent in their resources and revenues.

On the other hand, companies also spend quite a money in understanding user’s traffic patterns, monitoring network bandwidth utilization and WAN traffic, and performance monitoring. Whatever is their motive, some sort of protocol is needed to do all this as traditional method of monitoring via SNMP is just not enough and this give rise to Network protocol by Cisco called “Netflow”.

“NetFlow” is a network protocol developed by Cisco for collecting IP traffic information and monitoring network traffic. By analyzing flow data, a picture of network traffic flow and volume can be built. Using a NetFlow collector and analyzer, you can see where network traffic is coming from and going to and how much traffic is being generated.

While the term NetFlow was mostly used by Cisco, many other network hardware manufacturers support alternative flow technologies:

  • Juniper (Jflow)
  • 3Com/HP , Dell (s-flow)
  • Huawei (NetStream)
  • Alcatel-Lucent (Cflow)

Routers and switches that support NetFlow collect IP traffic statistics on all interfaces where NetFlow is enabled, and later export those statistics as NetFlow records, toward at least one NetFlow collector. Network collector is typically a server that does the actual traffic analysis. The NetFlow collector then processes the data to perform the traffic analysis and presentation in a user-friendly format. NetFlow collectors can take the form of hardware based collectors or software based collectors.

Netflow picture 1

 

NetFlow_Picture 2

 

NetFlow v1 was originally introduced in 1990 and has since evolved to NetFlow version 9. Today, the most common versions are v5 and v9. Major difference between v5 and v9 version is that v5 is restricted to IPv4 flows however v9 can be used to report flows like IPv6, MPLS, or even plain IPv4 with BGP nexthop.

Monitoring IP traffic flows ensures that resources are used appropriately in support of organizational goals. It helps IT determine where to apply Quality of Service (QoS), plays a vital role in network security to detect Denial-of-Service (DoS) attacks, and other undesirable network events.

One last thing is, Netflow is not a standardized version of protocol and it was developed by Cisco however other vendors uses the same concept for their routers/switches. IETF took the Netflow v9 and standardized this protocol into “IP-FIX” (IP Flow Information Export) with some additional changes which vendors are implementing these days to have a consistent view and avoiding any inter-operability issues.

We can go through the IP-FIX in other blogs but for now I hope you have understood the usage of Netflow :).

Thanks

Mohit Mittal