PCEP Initiated LSP using OpenDayLight and Juniper vMX

Hi All

In this post, we will look at Open day light controller working with Juniper vMXs and how we can use the controller to get the BGP, BGP-LS and PCEP working. Once everything is up and running we will use the Controller to initiate the PCEP initiated MPLS LSPs between 2 VMXs.

Sounds interesting? Let’s see how we can achieve this.

Before I go further, if you want to check anything on PCEP and some of its concept, I did a post on Juniper Northstar Controller some time ago which you can check.

https://networkzblogger.com/2017/03/17/juniper-northstar-wan-sdn-controller/

Below is the topology we will be using where all Juniper VMXs are loaded in Virtual Control Plane mode and they have fxp0 interface in 192.168.71.x subnet. Open day light controller version is Nitrogen and we have booted it on CentOS 7.5 version.

There is Windows VM in same subnet also from where we will run the REST APIs calls to Open day light using POSTMAN App.

Topology Diagram
Topology Diagram

 

We will divide the post into 3 parts.

  • Configuring BGP/BGP-Link state between ODL and 192.168.71.24 VMX-3.
  • Configuring PCEP session between all VMXs and ODL
  • Initiate MPLS LSP from ODL using PCEP

I am assuming that you already know how to start an ODL controller. However if you don’t know let me know and I can help you.

So lets start with 1) Configuring BGP/BGP-Link state between ODL and 192.168.71.24 VMX-3.

If you already don’t know, Open day light versions in recent times doesn’t come auto-installed with all the features. You have to manually add them. You don’t need to download them individually. It’s just you need to activate them.

We will be configure the BGP and BGP-LS on VMX-3 first

Standard BGP config with IPv4 Unicast address family however for BGP-LS we have to enable a separate family traffic-engineering additionally.

root@VMX-3> show configuration protocols bgp
group opendaylight {
 type internal;
 description Controller;
 local-address 192.168.71.24;
 family inet {
 unicast;
 }
 family traffic-engineering {
 unicast;
 }
 peer-as 2856;
 neighbor 192.168.71.22;
}

On ODL side, First install the BGP and restconf feature on karaf console using command

feature:install odl-restconf odl-bgpcep-bgp

Then using REST API we will enable the BGP Router-ID with Link State family

POST URL : 192.168.71.22:8181/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols

POST Request_BGP Router ID
POST Request_BGP Router ID

Then Configure the peer 192.168.71.24 with specific BGP Parameters and families

POST URL: 192.168.71.22:8181/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-test-odl/bgp/neighbors

POST Request_BGP Peer
POST Request_BGP Peer

We can check the status of BGP peering off course from VMX side but let’s see what comes up from ODL side

GET URL: 192.168.71.22:8181/restconf/operational/bgp-rib:bgp-rib/rib/bgp-test-odl/peer/bgp:%2F%2F3.3.3.3

GET Request_BGP Peering
GET Request_BGP Peering

From VMX side:

root@VMX-3> show bgp neighbor
Peer: 192.168.71.22+27755 AS 2856 Local: 192.168.71.24+179 AS 2856
 Description: Controller
 Group: opendaylight Routing-Instance: master
 Forwarding routing-instance: master
 Type: Internal State: Established Flags: <Sync>
 Last State: OpenConfirm Last Event: RecvKeepAlive
 Last Error: None
 Options: <Preference LocalAddress LogUpDown AddressFamily PeerAS Refresh>
 Options: <VpnApplyExport DropPathAttributes>
 Address families configured: inet-unicast te-unicast
 Path-attributes dropped: 128
 Local Address: 192.168.71.24 Holdtime: 90 Preference: 170
 Number of flaps: 2
 Last flap event: RecvNotify
 Error: 'Cease' Sent: 0 Recv: 33
 Peer ID: 192.168.71.22 Local ID: 3.3.3.3 Active Holdtime: 90
 Keepalive Interval: 30 Group index: 0 Peer index: 0 SNMP index: 0
 I/O Session Thread: bgpio-0 State: Enabled
 BFD: disabled, down
 NLRI for restart configured on peer: inet-unicast te-unicast

 

BGP-LS configuration we did will be used to advertise the Traffic Engineering database to Controller. You can see the routes advertised using lsdist.0 table in juniper.

Snippet below:

root@VMX-3> show route table lsdist.0
lsdist.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:2856 Area:0.0.0.0 IPv4:2.2.2.2 OSPF:0 }/1152
 *[OSPF/10] 02:02:38
 Fictitious
NODE { AS:2856 Area:0.0.0.0 IPv4:3.3.3.3 OSPF:0 }/1152
 *[OSPF/10] 02:02:43
 Fictitious
NODE { AS:2856 Area:0.0.0.0 IPv4:4.4.4.4 OSPF:0 }/1152
 *[OSPF/10] 02:02:38
 Fictitious
NODE { AS:2856 Area:0.0.0.0 IPv4:4.4.4.4-192.168.71.26 OSPF:0 }/1152
 *[OSPF/10] 02:02:31
 Fictitious
LINK { Local { AS:2856 Area:0.0.0.0 IPv4:2.2.2.2 }.{ IPv4:192.168.71.23 } Remote { AS:2856 Area:0.0.0.0 IPv4:4.4.4.4-192.168.71.26 }.{ } OSPF:0 }/1152
 *[OSPF/10] 02:02:31
 Fictitious
..
…
…

 

2) Now let’s configure the PCEP

On VMX (This will be repeated on all with change in local address)

root@VMX-3> show configuration protocols pcep
pce odl {
 local-address 192.168.71.24;
 destination-ipv4-address 192.168.71.22;
 destination-port 4189;
 pce-type active stateful;
 lsp-provisioning;
 p2mp-lsp-report-capability;
}

If you have any firewall, make sure to allow port 4189 between Controller and VMXs.

On ODL, we need to install odl-bgpcep-pcep feature

There is no other config to do. As soon as you install this feature, you should see PCEP status up.

Let’s see it from VMX-4

 

root@VMX-4> show path-computation-client status
Session Type            Provisioning Status
odl     Stateful Active On           Up

LSP Summary
 Total number of LSPs : 0
 Static LSPs : 0
 Externally controlled LSPs : 0
 Externally provisioned LSPs : 0/16000 (current/limit)
 Orphaned LSPs : 0

odl (main)
 Delegated : 0
 Externally provisioned : 0

From ODL side:

GET Request_PCEP Status
GET Request_PCEP Status

3)      PCEP Initiated LSP

Now, we will configure the LSP from VMX-3 to VMX-4 between their Loopback IPs.

POST URL: 192.168.71.22:8181/restconf/operations/network-topology-pcep:add-lsp

You can see we haven’t given any ERO while provisioning the LSP. ODL has auto calculated the path and you can verify in VMX-3

PCEP LSP ADD with No Ero
PCEP LSP ADD with No Ero
root@VMX-3> show mpls lsp name test-pcep-2 extensive
Ingress LSP: 1 sessions

4.4.4.4
 From: 3.3.3.3, State: Up, ActiveRoute: 0, LSPname: test-pcep-2
 ActivePath: (primary)
 LSPtype: Externally provisioned, Penultimate hop popping
 LSP Control Status: Externally controlled
 LoadBalance: Random
 Encoding type: Packet, Switching type: Packet, GPID: IPv4
 LSP Self-ping Status : Enabled
 *Primary State: Up, Preference: 200
 Priorities: 0 0
 External Path CSPF Status: external
 SmartOptimizeTimer: 180
 Flap Count: 0
 MBB Count: 0
 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
 192.168.71.26(Label=0)
 12 May 24 12:10:08.334 Self-ping ended successfully
 11 May 24 12:10:07.830 EXTCTRL LSP: Sent Path computation request and LSP status
 10 May 24 12:10:07.830 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 0 hold 0
 9 May 24 12:10:07.829 Selected as active path
 8 May 24 12:10:07.828 EXTCTRL LSP: Sent Path computation request and LSP status
 7 May 24 12:10:07.828 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 0 hold 0
 6 May 24 12:10:07.828 Up
 5 May 24 12:10:07.828 Self-ping started
 4 May 24 12:10:07.828 Self-ping enqueued
 3 May 24 12:10:07.828 Record Route: 192.168.71.26(Label=0)
 2 May 24 12:10:07.824 Originate Call
 1 May 24 12:10:07.824 EXTCTRL_LSP: Received setup parameters ::
 Created: Thu May 24 12:10:07 2018
Total 1 displayed, Up 1, Down 0

 

You can do various operations like Deleting LSP, Modifying LSP etc from REST API.

One thing which we can’t do at the moment using PCEP is configuring Point to Multipoint LSP as standard is still being drafted for this but I hope it will come out soon.

So that’s all for now, I hope you enjoyed it and let me know your feedback.

 

Regards

Mohit

 

EVPN in JunOS

Hi All

This time we will be looking at EVPN, its configuration on JunOS and how it is different from VPLS.

Currently if service provider has to join customer’s multiple sites via Layer 2, only option is VPLS. VPLS can be LDP based or BGP based.

BGP based VPLS has advantages that you can use RRs to scale however VPLS as a whole has a disadvantages that:

  • We can’t do active-active multihoming with both links from CE to PE.
  • Control plane MAC-Learning is not possible.
  • L2 Loop detection is not possible.
  • VPLS consumes less in control plane however more MPLS labels (because MAC learning relies on a different label for each remote site) than EVPN.

EVPN is immune to all the above problems and it’s only based upon BGP so we don’t have to fight between LDP vs BGP advantages.

Underlying EVPN can be used with VXLAN or MPLS however solution which I am going to discuss is based upon MPLS.

Look at the diagram below. We have 3 sites basically 3 VMs all part of same IP Network and they are connected to same EVPN instances on 3 different Juniper routers via switch in their path.

EVPN
EVPN Topology

Let’s see config on Manchester Juniper PE router.

You can see its fairly straightforward config with same parameters as L3VPNs except instance-type is evpn and we need to use protocols evpn to define parameters to limit the mac and ip if we want.

write@re1.Manchester > show configuration routing-instances evpn-1
instance-type evpn;
vlan-id 1200;
interface xe-1/0/0:0.1200;
route-distinguisher 10.198.206.41:1200;
vrf-target target:2856:1200;
protocols {
 evpn {
 interface-mac-limit {
 1000;
 packet-action drop;
 }
 interface-mac-ip-limit {
 1000;
 }
 interface xe-1/0/0:0.1200;
 label-allocation per-instance;
 }
}

From RR point of view, we need to add family evpn under BGP on all PEs and RR.

write@re1.Manchester > show configuration protocols bgp
path-selection external-router-id;
advertise-from-main-vpn-tables;
log-updown;
drop-path-attributes 128;
authentication-algorithm md5;
vpn-apply-export;
tcp-mss 4096;
group LAB-RR {
 type internal;
 local-address 10.198.206.41;
 family inet-vpn {
 unicast;
 family l2vpn {
 signaling;
 }
 family evpn {
 signaling;
 }
 neighbor 10.198.206.46;
}

We will be doing the same configs on rest 2 PEs.

write@re1.Manchester > show evpn instance evpn-1 extensive
Instance: evpn-1
 Route Distinguisher: 10.198.206.41:1200
 VLAN ID: 1200
 Per-instance MAC route label: 119
 Per-instance multicast route label: 120
 Duplicate MAC detection threshold: 5
 Duplicate MAC detection window: 180
 MAC database status Local Remote
 MAC advertisements: 1 2
 MAC+IP advertisements: 1 2
 Default gateway MAC advertisements: 0 0
 Number of local interfaces: 3 (3 up)
 Interface name ESI Mode Status AC-Role
 et-1/1/0.1200 00:00:00:00:00:00:00:00:00:00 single-homed Up Root
 xe-1/0/0:0.1200 00:00:00:00:00:00:00:00:00:00 single-homed Up Root
 xe-1/0/0:0.1210 00:00:00:00:00:00:00:00:00:00 single-homed Up Root
 Number of IRB interfaces: 0 (0 up)
 Number of protect interfaces: 0
 Number of bridge domains: 1
 VLAN Domain ID Intfs / up IRB intf Mode MAC sync IM route label SG sync IM core nexthop
 1200 3 3 Extended Enabled 120 Enabled
 Number of neighbors: 4
 Address MAC MAC+IP AD IM ES Leaf-label
 10.198.206.42 0 0 0 1 0
 10.198.206.43 1 1 0 1 0
 10.198.206.44 0 0 0 1 0
 10.198.206.45 1 1 0 1 0
 Number of ethernet segments: 0

Some key take away from above is that due to config “label-allocation per-instance” we are seeing one MPLS Label for the whole EVPN routing instance.

write@re1.Manchester > show route table mpls.0 label 119
mpls.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

119 *[EVPN/7] 3d 20:05:21, routing-instance evpn-1, route-type Ingress-MAC, vlan-id 1200
 to table evpn-1.evpn-mac.0

ESI (Ethernet Segment Identifier) is all zeros for PE which is single homed to CE. In active-active multihoming, an Ethernet segment appears as a LAG to the CE device.

Let’s check the mac-table on PE. So you can see   00:0c:29:34:04:26 is learned dynamically by Manc PE over xe-1/0/0:0/1200 interface. This is still Data Plane learning and with EVPN there is no difference. However look at MAC Flags for other 2 MAC addresses. DC corresponds to Dynamic Control MAC means they are learned via Control Plane (using BGP)

write@re1.Manchester > show evpn mac-table instance evpn-1
MAC flags       (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC, P -Pinned MAC)
Routing instance : evpn-1
Bridging domain : __evpn-1__, VLAN : 1200
MAC                         MAC      Logical          NH     MAC         active
address                    flags    interface        Index  property    source
00:0c:29:34:04:26   D        xe-1/0/0:0.1200
00:0c:29:37:55:3d   DC                        1048585            10.198.206.43
00:0c:29:55:5a:45   DC                        1048584            10.198.206.45

Evpn has also learned the IP Address and added in arp-table so you can see MAC/IP Association.

write@re1.Manchester > show evpn arp-table instance evpn-1
INET MAC Logical Routing Bridging
address address interface instance domain
10.10.10.3 00:0c:29:34:04:26 xe-1/0/0:0.1200 evpn-1 __evpn-1__
10.10.10.4 00:0c:29:37:55:3d evpn-1 __evpn-1__
10.10.10.2 00:0c:29:55:5a:45 evpn-1 __evpn-1__

Same thing you can see in routing table as well.

There are several types of routes in EVPN, Type 1, 2, 3, 5, 6 etc.. Type 2 is MAC and IP Route which shows relationship between them however Junos shows that also in 2 ways. Type 2 route as pure MAC and type 2 route as MAC/IP.

Type 3 routes are required for Broadcast, Unknown Unicast and Multicast (BUM) traffic delivery across EVPN networks. Type 3 advertisements provide information about P-tunnels that should be used to send BUM traffic. Without Type 3 advertisements, ingress router would not know how to deliver BUM traffic to other PE devices that comprise given EVPN instance.

write@re1.Manchester > show route table evpn-1
evpn-1.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:10.198.206.41:1200::1200::00:0c:29:34:04:26/304 MAC/IP
 *[EVPN/170] 3d 19:18:39
 Indirect
2:10.198.206.43:1200::1200::00:0c:29:37:55:3d/304 MAC/IP
 *[BGP/170] 1d 02:03:17, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.2 via xe-0/0/0:1.0
2:10.198.206.45:1200::1200::00:0c:29:55:5a:45/304 MAC/IP
 *[BGP/170] 03:13:24, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.14 via et-0/1/0.0, Push 945
2:10.198.206.41:1200::1200::00:0c:29:34:04:26::10.10.10.3/304 MAC/IP
 *[EVPN/170] 3d 19:18:34
 Indirect
2:10.198.206.43:1200::1200::00:0c:29:37:55:3d::10.10.10.4/304 MAC/IP
 *[BGP/170] 01:53:03, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.2 via xe-0/0/0:1.0
2:10.198.206.45:1200::1200::00:0c:29:55:5a:45::10.10.10.2/304 MAC/IP
 *[BGP/170] 03:13:24, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.14 via et-0/1/0.0, Push 945
3:10.198.206.41:1200::1200::10.198.206.41/248 IM
 *[EVPN/170] 6d 22:17:38
 Indirect
3:10.198.206.42:1200::1200::10.198.206.42/248 IM
 *[BGP/170] 03:13:24, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.14 via et-0/1/0.0
3:10.198.206.43:1200::1200::10.198.206.43/248 IM
 *[BGP/170] 1d 02:03:17, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.2 via xe-0/0/0:1.0
3:10.198.206.44:1200::1200::10.198.206.44/248 IM
 *[BGP/170] 1d 02:03:17, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.6 via xe-0/0/0:2.0
3:10.198.206.45:1200::1200::10.198.206.45/248 IM
 *[BGP/170] 03:13:24, localpref 100, from 10.198.206.46
 AS path: I, validation-state: unverified
 > to 30.30.30.14 via et-0/1/0.0, Push 945

 

Let’s do a ping test from VM (10.10.10.4) connected to London to VM (10.10.10.3) connected to Manchester PE via EVPN Network.

For completeness, I have shown the arp-table for London EVPN-1.

write@re0.London > show evpn arp-table instance evpn-1
INET MAC Logical Routing Bridging
address address interface instance domain
10.10.10.3 00:0c:29:34:04:26 evpn-1 __evpn-1__
10.10.10.4 00:0c:29:37:55:3d xe-0/2/0.1200 evpn-1 __evpn-1__
10.10.10.2 00:0c:29:55:5a:45 evpn-1 __evpn-1__

You can see Ping works without any loss.

Ping

So that’s all for EVPN. Let me know if you have any queries and I hope to show you more in next blogs about EVPN.

BBye 🙂

Mohit

Segment Routing v/s RSVP-TE?

SR (Segment Routing) is new and trending topic these days in Telecom Networks. It’s promising and some vendors are pushing for it because of the way we can leverage SDN Controller to steer the traffic through the Network plus how it will remove need of LDP/RSVPE-TE from core however i think there are still some of the use cases where it lacks some capabilities currently. I hope in future all these areas will be fixed and SR becomes THE Option of choice for all Service Providers. These are all my opinions and it would be good to know your views on it.

1)      Bandwidth Reservation issue –> Using SR we can’t reserve the bandwidth in our Network for each LSP as we can do with RSVP-TE. Bandwidth reservation can be critical in some Service provider/Broadcast networks to provide the customer with dedicated bandwidth. We can argue that Controller at the Top can look at the whole Network and would be able to easily manage the reservations however Controller is a single point of failure and I don’t think we can depend upon Controller for this crucial behaviour.?

2)      Lack of Multicast P2MP Support –> Multicast proposes more challenge for the segment routing. SR can only replace Point to point LDP/RSVP-TE however some of the Telecom Networks uses P2MP Multicast services as part of NG-MVPN and for those we still need to depend on RSVP-TE . Moreover MPLS-based multicast solutions have matured now after many years’ of development. I think keeping 2 Technologies i.e one for P2P L2/L3VPN and other for P2MP MVPN will add complexity only to network.

3)      Depth of MPLS Label Stack –> We know that forwarding packets need to push a SR header with a list of segments(labels). Now there are 2 main types of SR Labels. One is Node and other is Adjacency (link). To provide granularity to route the traffic via 15-20 hops we need to push more Adjacency labels at Ingress PE accordingly. This depth of label stack may be a challenge for some type of devices.

Plz see some of the labels stack present in hardware:  (Courtesy: NANOG.org)

Linux (kernel 4.10): 2-3 SID’s

Low end off the shelf (merchant) silicon, e.g. BCM Trident2: 3-5 SID’s

High end off the shelf (merchant) silicon, e.g BCM Jericho1 : 4-7 SID’s

Vendor’ silicon, e.g. Juniper’ Trio: 4-10+ SID’s

Even though Vendor may be able to support 15-20 Label stack, we can end up in payload efficiency and MTU issues i.e. because of big size of the header will reduce the efficiency of payload.

4)      State Issues –> One major advantage for segment routing proposed was that the State is only maintained at the head-end. No state is maintained at mid-points and tail-ends. This is good in case if we have Node and Adjacency/Link labels only however there are proposals for Prefix segment Labels also which will increase the state on all the points in network and I don’t think behaviour will be different from LDP/RSVP-TE then.

In case of centrally controlled environment where Controller will take care of everything it will be difficult for Operations Teams to troubleshoot in case anything goes wrong in Network as they need to know the architecture of each device whether it is capable of getting around the Label stack issue via that device. We may be thinking of putting low end devices near to Customer edge as PEs and high end in middle of core, however due to label stack issue we may need to put high end routers only everywhere.

I am not against SR however i would be really pleased if these issues can be taken care or already available (i may well be living in old times) however from my perspective, there is scalability issue which limits application scenarios for segment routing. It may be better for cases where service provider is mostly providing  unicast L2/L3VPN services.

Let me know your views on this and how you are using SR in your environment 🙂

 

 

JunOS Automation using PyEZ and Northstar REST APIs

Hi All, in this session lets discuss some Automation.

During past few days, I was looking at some REST APIs for Juniper Northstar Controller. Now Northstar is good for LSP creation/deletion/modification but it cant configure the service E2E. Offcourse that tool is not meant to do all this but Juniper has recently released one beta version of it which can bind your LSP to some service which is excellent step forward. We will see that in a moment. Juniper is leveraging Jinja templates in NS to achieve this binding.

However as I said still service creation is not E2E and for that I thought of adding one more layer of automation and for this I have used Juniper own PyEZ framework which is basically Juniper Python library for automating tasks. Brilliant lets see how this work.

Juniper PyEZ is a framework which is easily grasped by Network engineers and you don’t need to be programmer to fully understand it.

https://www.juniper.net/documentation/en_US/junos-pyez/topics/concept/junos-pyez-overview.html

REST (REpresentational State Transfer) is a set of useful conventions and principals about transfer of information over the World Wide Web.

Many Web services are now using the principals of REST in their design.

When you type a URL into your browser, like http://example.net, your browser software creates an HTTP header that identifies:

  • a desired action: GET (“get me this resource”).
  • a target machine (www.domain-name.com).

The NorthStar RESTful APIs are designed to enable access over HTTP to most of the same data and analytics that are available to you from both the NorthStar GUI and the NorthStar CLI.

https://www.juniper.net/documentation/en_US/northstar3.1.0/information-products/api-ref/api-ref.html

Below is the pictorial representation of what we will be doing. I have used a Windows server on which we will write a script which will talk to Northstar using REST APIs and other components of Juniper Pes using PyEZ.

L2VPN CCC
Automation Model

 

Our Script will be written in Python and you can write the variables value in excel and pass it to the script.

Our excel format:

L2VPN_CCC_Data

import httplib
import json
import time
import re
import sys
import pandas as pd
from jnpr.junos import Device
from jnpr.junos.utils.config import Config
from pprint import pprint

df = pd.read_excel("L2VPN_CCC_Data.xlsx","Sheet1")

PE1 = str((df['PE1'].values.tolist())[0])
PE2 = str((df['PE2'].values.tolist())[0])
Interface_PE1 = str((df['Interface_PE1'].values.tolist())[0])
Unit_PE1 = str((df['Unit_PE1'].values.tolist())[0])
Vlan_PE1 = str((df['Vlan_PE1'].values.tolist())[0])
Interface_PE2 = str((df['Interface_PE2'].values.tolist())[0])
Unit_PE2 = str((df['Unit_PE2'].values.tolist())[0])
Vlan_PE2 = str((df['Vlan_PE2'].values.tolist())[0])
LSP_Name_PE1 = str((df['LSP_Name_PE1'].values.tolist())[0])
LSP_Name_PE2 = str((df['LSP_Name_PE2'].values.tolist())[0])
VPN_CCC_PE1 = str((df['VPN_CCC_PE1'].values.tolist())[0])
VPN_CCC_PE2 = str((df['VPN_CCC_PE2'].values.tolist())[0])

dev1 = Device(host=''+PE1+'', user='demo', password='password', port='22')
dev1.open()
dev1.timeout = 300

with Config(dev1, mode='private') as cu: 
cu.load('set interfaces '+Interface_PE1+' unit '+Unit_PE1+' description L2VPN-CCC encapsulation vlan-ccc vlan-id '+Vlan_PE1+' family ccc', format='set')
cu.pdiff() #Printing the difference in the configuration after the load
cu.commit()

dev1.close()
dev2 = Device(host=''+PE2+'', user='demo', password='password', port='22')
dev2.open()
dev2.timeout = 300

with Config(dev2, mode='private') as cu: 
cu.load('set interfaces '+Interface_PE2+' unit '+Unit_PE2+' description L2VPN-CCC encapsulation vlan-ccc vlan-id '+Vlan_PE2+' family ccc', format='set')
cu.pdiff() #Printing the difference in the configuration after the load#
cu.commit() #commit#

dev2.close()
conn = httplib.HTTPConnection('10.198.123.180:8091')
Bandwidth = raw_input('Please enter LSP Bandwidth on '+PE1+' (e.g 100k): ')
Setup_Pri = raw_input('Please enter Set up Priority: ')
Hold_Pri = raw_input('Please enter Hold Priority: ')
payload = str('{\r\n\"name\": \"'+LSP_Name_PE1+'\",\r\n\"creationConfigurationMethod\": \"NETCONF\",\r\n\"provisioningType\": \"RSVP\",\r\n  \"pathType\": \"primary\",\r\n  \"from\": {\r\n\"topoObjectType\": \"ipv4\",\r\n\"address\": \"'+PE1+'\"\r\n },\r\n  \"to\": {\r\n\"topoObjectType\": \"ipv4\",\r\n\"address\": \"'+PE2+'\"\r\n},\r\n\"plannedProperties\": {\r\n\"bandwidth\": \"'+Bandwidth+'\",\r\n\"setupPriority\": '+Setup_Pri+',\r\n\"holdingPriority\": '+Hold_Pri+',\r\n\"userProperties\": {\r\n \"ccc-vpn-name\": \"'+VPN_CCC_PE1+'\",\r\n \"ccc-interface\": \"'+Interface_PE1+'.'+Unit_PE1+'\",\r\n\"transmit-lsp\": \"'+LSP_Name_PE1+'\",\r\n\"receive-lsp\": \"'+LSP_Name_PE2+'\"\r\n    }\r\n  }\r\n}\r\n')
headers = {
 'content-type': "application/json",
'cache-control': "no-cache",
 }

conn.request ("POST", "/NorthStar/API/v2/tenant/1/topology/1/te-lsps", payload, headers
res = conn.getresponse()
data = res.read()
print 'Please wait while we get the status of LSP you created :)'
for i in xrange(25,0,-1):
 time.sleep(1)
 sys.stdout.write(str(i)+' ') 
 sys.stdout.flush()
 conn.request("GET", str('/NorthStar/API/v2/tenant/1/topology/1/te-lsps/search?name=' + LSP_Name_PE1), headers=headers
 res = conn.getresponse()
 data = res.read()

LSP_Status = re.search('operationalStatus":(.*?),', data).group(1)
if LSP_Status == '"Active"':
  print ('\nSuccess: LSP "'+LSP_Name_PE1+'" is Created and Active')
elif LSP_Status == "Down":
   print ('\nFailed: LSP "'+LSP_Name_PE1+'" is created however Down')
else:
  print ('\nFailed: LSP "'+LSP_Name_PE1+'" is not created and is in Unknown State on Northstar')

time.sleep(10)

conn = httplib.HTTPConnection('10.198.123.180:8091')
Bandwidth = raw_input('Please enter LSP Bandwidth on '+PE2+' (e.g 100k): ')
Setup_Pri = raw_input('Please enter Set up Priority: ')
Hold_Pri = raw_input('Please enter Hold Priority: ')

payload = str('{\r\n\"name\": \"'+LSP_Name_PE2+'\",\r\n\"creationConfigurationMethod\": \"NETCONF\",\r\n\"provisioningType\": \"RSVP\",\r\n  \"pathType\": \"primary\",\r\n  \"from\": {\r\n\"topoObjectType\": \"ipv4\",\r\n\"address\": \"'+PE2+'\"\r\n },\r\n  \"to\": {\r\n\"topoObjectType\": \"ipv4\",\r\n\"address\": \"'+PE1+'\"\r\n},\r\n\"plannedProperties\": {\r\n\"bandwidth\": \"'+Bandwidth+'\",\r\n\"setupPriority\": '+Setup_Pri+',\r\n\"holdingPriority\": '+Hold_Pri+',\r\n\"userProperties\": {\r\n \"ccc-vpn-name\": \"'+VPN_CCC_PE2+'\",\r\n \"ccc-interface\":\"'+Interface_PE2+'.'+Unit_PE2+'\",\r\n\"transmit-lsp\": \"'+LSP_Name_PE2+'\",\r\n\"receive-lsp\": \"'+LSP_Name_PE1+'\"\r\n    }\r\n  }\r\n}\r\n')
headers = {
 'content-type': "application/json",
 'cache-control': "no-cache",
   }

conn.request ("POST", "/NorthStar/API/v2/tenant/1/topology/1/te-lsps", payload, headers)
res = conn.getresponse()
data = res.read()
print 'Please wait while we get the status of LSP you created :)'
for i in xrange(25,0,-1):
   time.sleep(1)
   sys.stdout.write(str(i)+' ')
   sys.stdout.flush()

conn.request("GET", str('/NorthStar/API/v2/tenant/1/topology/1/te-lsps/search?name=' + LSP_Name_PE2), headers=headers)
res = conn.getresponse()
data = res.read()
LSP_Status = re.search('operationalStatus":(.*?),', data).group(1)
if LSP_Status == '"Active"':
    print ('\nSuccess: LSP "'+LSP_Name_PE2+'" is Created and Active')
elif LSP_Status == "Down":
    print ('\nFailed: LSP "'+LSP_Name_PE2+'" is created however Down')
else:
    print ('\nFailed: LSP "'+LSP_Name_PE2+'" is not created and is in Unknown State on Northstar')

time.sleep(5)

dev1.open()
dev2.open()

print (dev1.cli('show connections remote-interface-switch '+VPN_CCC_PE1+'', warning=False))

print (dev2.cli('show connections remote-interface-switch '+VPN_CCC_PE2+'', warning=False))

dev1.close()
dev2.close()

In this script we are making reading the values from the excel and using it as variables in or script.

After that using PyEZ, making a SSH connection to PE1 and PE2 and configuring the layer 2 sub-interfaces with vpn-ccc encapsulations. Once that is done, connection to Northstar server 10.198.123.180 using httplib libraris/modules is made and waiting for Northstar to configure the LSP. At this stage Northstar is also binding that LSPs in connections using Jinja template. Once Northstar has created the LSPs we are using regular expression to get the LSP Index from Northstar and checking whether LSP creating in Success or failed.

At last we are printing the show command output to find out if everything is up and running 🙂

Lets see by running the script

C:\Program Files (x86)\Python\Northstar_Scripts\Working\Juniper\L2VPN_CCC>python
 E2E_L2VPN_CCC_Script.py
[edit interfaces xe-2/0/0]
+ unit 601 {
+ description L2VPN-CCC;
+ encapsulation vlan-ccc;
+ vlan-id 601;
+ family ccc;
+ }
[edit interfaces xe-2/0/0]
+ unit 601 {
+ description L2VPN-CCC;
+ encapsulation vlan-ccc;
+ vlan-id 601;
+ family ccc;
+ }
Please enter LSP Bandwidth on 10.198.123.100 (e.g 100k): 70m
Please enter Set up Priority: 5
Please enter Hold Priority: 0
Please wait while we get the status of LSP you created :)
25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Success: LSP "l2vpn-ccc-1" is created and is Active
Please enter LSP Bandwidth on 10.198.123.205 (e.g 100k): 70m
Please enter Set up Priority: 5
Please enter Hold Priority: 0
Please wait while we get the status of LSP you created :)
25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Success: LSP "l2vpn-ccc-2" is created and is Active
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 tran
s
l2vpn-ccc rmt-if Up Nov 25 12:52:10
1
 xe-2/0/0.601 intf Up
 l2vpn-ccc-1 tlsp Up
 l2vpn-ccc-2 rlsp Up

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 tran
s
l2vpn-ccc rmt-if Up Nov 25 12:52:11
1
 xe-2/0/0.601 intf Up
 l2vpn-ccc-2 tlsp Up
 l2vpn-ccc-1 rlsp Up

C:\Program Files (x86)\Python\Northstar_Scripts\Working\Juniper\L2VPN_CCC>

 

So that’s all for today.. You can see the possibility of using this framework in so many tasks in your daily networking journey. I hope you like this blog and will try to use it in your network 🙂

Regards

Mohit

Juniper Northstar SDN Controller – Part 2

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

 

Ansible on JunOS

Hi All, first of all sorry for coming out late with next blog. Was busy in some personal and official stuff.

Also during past few days, I have been exploring having Ansible set up in our network for ease of configuring and having a centralised place to do some configuration on single or all boxes at once.

Ansible if you don’t know is Configuration Management, software provisioning tool. Ansible is in same league as Puppet, Chef, Salt provisioning tool but its different from them in some sense like Pull vs Push, Stateless vs Stateful etc. We will discuss these difference below but Ansible on top provides configuration/provisioning support for Network engineers in a sense that it has modules from different vendors like Cisco, Huawei, Arista, Nokia and Juniper. We will specifically discuss about Junos here.

Juniper provides support for using Ansible to deploy devices running the Junos operating system (Junos OS). The Juniper Networks Ansible library, which is hosted on the Ansible Galaxy website under the role junos, enables you to use Ansible to perform specific operational and configuration tasks on devices running Junos OS, including installing and upgrading, deploying specific devices in the network, loading configuration changes, retrieving information, and resetting, rebooting, or shutting down managed devices.

I have just started to explore Ansible so I am really Amateur in this area however may be after some months of work I will be in position to provide more details on this 🙂 . Before we dive into some examples let’s review what I said before regarding differences.

Push vs Pull –> Puppet basically works on Pull mechanism where its hosts periodically pulls the configurations from server which is good for some things but not if you want change to deployed asap. On the other hand Ansible works in Push model where config is applied instantly to nodes/hosts.

Stateless vs Stateful –> Ansible works in stateless mode where to use Ansible, nothing needs to be installed on Hosts i.e. switches/routers. Ansible and other libraries are installed on Server which is controller and it connects to nodes/hosts via SSH/Netconf.

For Ansible to work with Junos, 3 requirements needs to be fulfilled first on server.

1)      pip install ncclient  (this is python lib for netconf)

2)      pip install junos-eznc (this is python lib for Junos)

3)      Install Juniper.junos Galaxy role using command:

ansible-galaxy install Juniper.junos

Once this is done, we can run raw modules from Ansible server as Ad-hoc commands which basically uses SSH instead of netconf.

I am running ansible on CentOS 6.9

 

mmittal@ANS01$ cat /etc/redhat-release
CentOS release 6.9 (Final)

So basically here we will be using raw module to check the version on host and we will provide the username with it and –k option will invoke us to put password.

ansible -v 10.198.123.103 -m raw -a "show version" -u mmittal –k
SSH password:
10.198.123.103 | SUCCESS | rc=0 >>
Hostname: MX-104-PE-Volvo
Model: mx104
Junos: 15.1F6.9
JUNOS Base OS boot [15.1F6.9]
JUNOS Base OS Software Suite [15.1F6.9]
JUNOS Crypto Software Suite [15.1F6.9]
JUNOS Packet Forwarding Engine Support (MX104) [15.1F6.9]
JUNOS Web Management [15.1F6.9]
JUNOS Online Documentation [15.1F6.9]
JUNOS Services Application Level Gateways [15.1F6.9]
JUNOS Services Jflow Container package [15.1F6.9]
JUNOS Services Stateful Firewall [15.1F6.9]
JUNOS Services NAT [15.1F6.9]
JUNOS Services RPM [15.1F6.9]
JUNOS Services Captive Portal and Content Delivery Container package [15.1F6.9]
JUNOS Macsec Software Suite [15.1F6.9]
JUNOS Services Crypto [15.1F6.9]
JUNOS Services IPSec [15.1F6.9]
JUNOS Kernel Software Suite [15.1F6.9]
JUNOS Routing Software Suite [15.1F6.9]
Shared connection to 10.198.123.103 closed.

This adhoc commands lets you check things without having to do any real programming however real use of Ansible comes via way of playbooks which are basically scripts in layman term. Under playbook we will mention the module which want to run and tasks to be performed. Before running Ansible playbook it is better to talk about one important file name called ansible.cfg which basically resides in etc/ansible/ansible.cfg

However ansible.cfg is picked up in following order and it is recommended to have our own ansible.cfg in current/home directory so that we can control the parameters we want to have.

* ANSIBLE_CONFIG (an environment variable)
* ansible.cfg (in the current directory)
* .ansible.cfg (in the home directory)
* .ansible.cdg (in /etc/ansible/ansible.cfg)

Example from my ansible.cfg which apart from standard defaults is also pointing to hostfile where all IP Addresses of routers/switches will reside.

mmittal@ANS01$ cat ansible.cfg
[defaults]
hostfile = ./ansible_hosts
host_key_checking = false
timeout = 5
log_path=./ansible.log

Lets see one example of playbook.

So in this playbook we are adding a task of running multiple commands on 2 hosts and module we have used in junos_command and we are printing the output on session.

mmittal@ANS01$ cat ansible_multiplecommands.yml
---
- name: show version and other user level commands
 hosts: 10.198.123.100, 10.198.123.103
 roles:
 - Juniper.junos
 gather_facts: no
 connection: local
tasks:
 - name: run multiple commands on remote nodes
 junos_command:
 commands:
 - show version
 - show interfaces

register: print_output

- debug: var=print_output.stdout_lines

To run this playbook we have to use the following command:

mmittal@ANS01$ ansible-playbook ansible_multiplecommands.yml -u mmittal -k
SSH password:

PLAY [show version and other user level commands] *************************************************************************************************************************************************************

TASK [run multiple commands on remote nodes] ******************************************************************************************************************************************************************
ok: [10.198.123.103]
ok: [10.198.123.100]

TASK [debug] **************************************************************************************************************************************************************************************************
ok: [10.198.123.100] => {
 "print_output.stdout_lines": [
 [
 "Hostname: re1.MX104_PE_Pagani",
 "Model: mx104",
 "Junos: 15.1F6.9",
 "JUNOS Base OS boot [15.1F6.9]",
 "JUNOS Base OS Software Suite [15.1F6.9]",
 "JUNOS Crypto Software Suite [15.1F6.9]",
 "JUNOS Packet Forwarding Engine Support (MX104) [15.1F6.9]",
 "JUNOS Web Management [15.1F6.9]",
 "JUNOS Online Documentation [15.1F6.9]",
 "JUNOS Services Application Level Gateways [15.1F6.9]",
 "JUNOS Services Jflow Container package [15.1F6.9]",
 "JUNOS Services Stateful Firewall [15.1F6.9]",
 "JUNOS Services NAT [15.1F6.9]",
 "JUNOS Services RPM [15.1F6.9]",
 "JUNOS Services Captive Portal and Content Delivery Container package [15.1F6.9]",
 "JUNOS Macsec Software Suite [15.1F6.9]",
 "JUNOS Services Crypto [15.1F6.9]",
 "JUNOS Services IPSec [15.1F6.9]",
 "JUNOS Kernel Software Suite [15.1F6.9]",
 "JUNOS Routing Software Suite [15.1F6.9]"
 ],
 [
 "Physical interface: ge-0/0/0, Enabled, Physical link is Up",
 " Interface index: 154, SNMP ifIndex: 512",
 " Description: Connected to MX104 RR-3_ge-0/1/0",
 " Link-level type: Ethernet, MTU: 1600, MRU: 1608, LAN-PHY mode,",
 " Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None,",
 " Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled,",
 " Auto-negotiation: Enabled, Remote fault: Online",
 " Pad to minimum frame size: Disabled",
 " Device flags : Present Running",
 " Interface flags: SNMP-Traps Internal: 0x0",
 " CoS queues : 8 supported, 8 maximum usable queues",
 " Current address: 54:1e:56:f7:78:00, Hardware address: 54:1e:56:f7:78:00",
 " Last flapped : 2017-08-18 13:32:41 GMT (2w3d 21:51 ago)",
 .
.
(o/p trunacated)
.
.
.
.
 ]
 ]
}
ok: [10.198.123.103] => {
 "print_output.stdout_lines": [
 [
 "Hostname: MX-104-PE-Volvo",
 "Model: mx104",
 "Junos: 15.1F6.9",
 "JUNOS Base OS boot [15.1F6.9]",
 "JUNOS Base OS Software Suite [15.1F6.9]",
 "JUNOS Crypto Software Suite [15.1F6.9]",
 "JUNOS Packet Forwarding Engine Support (MX104) [15.1F6.9]",
 "JUNOS Web Management [15.1F6.9]",
 "JUNOS Online Documentation [15.1F6.9]",
 "JUNOS Services Application Level Gateways [15.1F6.9]",
 "JUNOS Services Jflow Container package [15.1F6.9]",
 "JUNOS Services Stateful Firewall [15.1F6.9]",
 "JUNOS Services NAT [15.1F6.9]",
 "JUNOS Services RPM [15.1F6.9]",
 "JUNOS Services Captive Portal and Content Delivery Container package [15.1F6.9]",
 "JUNOS Macsec Software Suite [15.1F6.9]",
 "JUNOS Services Crypto [15.1F6.9]",
 "JUNOS Services IPSec [15.1F6.9]",
 "JUNOS Kernel Software Suite [15.1F6.9]",
 "JUNOS Routing Software Suite [15.1F6.9]"
 ],
 [
 "Physical interface: lc-0/0/0, Enabled, Physical link is Up",
 " Interface index: 142, SNMP ifIndex: 506",
 " Speed: 800mbps",
 " Device flags : Present Running",
 " Link flags : None",
 " Last flapped : Never",
 " Input packets : 0",
 " Output packets: 0",
 "",
 " Logical interface lc-0/0/0.32769 (Index 329) (SNMP ifIndex 507)",
 " Flags: Encapsulation: ENET2",
 " Bandwidth: 0",
 " Input packets : 0",
 " Output packets: 0",
 " Protocol vpls, MTU: Unlimited",
 " Flags: Is-Primary",
 "",
(o/p trunacated)
.
.
.
 ]
 ]
}

PLAY RECAP ****************************************************************************************************************************************************************************************************
10.198.123.100 : ok=2 changed=0 unreachable=0 failed=0
10.198.123.103 : ok=2 changed=0 unreachable=0 failed=0

 


So that’s all for today.. Its very basic intro to Ansible on Junos however I hope you get an idea and will try to use it in your network 🙂

Regards

Mohit