Tag Archives: RSVP

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

 

Advertisements

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

 

RSVP Messages in Juniper JunOS

RSVP (Resource Reservation Protocol) is a transport layer protocol designed to reserve resources across a network for an integrated services Internet. RSVP is not a routing protocol and was designed to interoperate with current and future routing protocols.

RSVP by itself is rarely deployed in telecom networks today but the traffic engineering extension of RSVP, or RSVP-TE, is becoming more widely accepted nowadays in many QoS-oriented networks

In this blog we will see the RSVP messages which flows while setting up the E2E LSP between 2 PEs.

Following model will be used to understand the behaviour.

RSVP
RSVP Messages Topology

LSP we will configure is TEST-MX960-MX104 between MX960 (Hostname : Bentley) and MX104 (Hostname Pagani) via M320 and M120.

Let’s configure the LSP as below from MX960 to MX104 (loopback IP: 10.198.123.100) with strict path through M320 and M120.

re1.bentley> show configuration protocols mpls label-switched-path TEST-MX960-MX104
to 10.198.123.100;
bandwidth 100m;
optimize-timer 900;
preference 200;
priority 5 0;
primary Bentley-Pagani;

re1.bentley> show configuration protocols mpls path Bentley-Pagani
10.0.0.93 strict;
10.0.0.41 strict;
10.0.0.170 strict;

Before we see the RSVP session details, lets see the message interactions happening at each device from Ingress to Egress. We enabled the RSVP traceoptions in order to capture the packets.

As soon as LSP is configured, RSVP new session is built with tunnel ID (44394 in our case) which is unique for this LSP and will be present in all messages.

Jun 25 18:32:31.822264 RSVP new Session 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0, session ID 51419

Jun 25 18:32:31.822301 RSVP new path state, session 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0

Path Messages:

Path message will be sent by Ingress PE MX960 towards MX104 hop by hop using the strict path we configured or will be based on IGP path in case no path has been defined.

MX960 will send the RSVP Send path message which will be received by Transit routers which in turn will send their own Path messages.

On MX960:

Jun 25 18:32:31.824365 RSVP send Path 10.198.123.205->10.198.123.100 Len=272 ge-1/1/7.0 flags=0x1 ttl=255
Jun 25 18:32:31.824385 Integty Len 36 flag 0x0 key 0x00005e00000a seq 0xbf015059de530a00 digest 0x75c574bd 0x3c7e8ecb 0x435976f8 0x408b3263
Jun 25 18:32:31.824399 MessageID Len 12 Msg_ID: 878279 Epoch: 2641670 (Ack Desired)
Jun 25 18:32:31.824415 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:31.824431 Hop Len 12 10.0.0.94/0x80000009
Jun 25 18:32:31.824443 Time Len 8 30000 ms
Jun 25 18:32:31.824464 SrcRoute Len 28 10.0.0.93 S 10.0.0.41 S 10.0.0.170 S
Jun 25 18:32:31.824477 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:31.824492 Properties Len 12 Primary path
Jun 25 18:32:31.824505 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:31.824520 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:31.824546 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:31.824560 ADspec Len 48 MTU 1500
Jun 25 18:32:31.824575 RecRoute Len 12 10.0.0.94

M120:

Jun 25 18:32:31.941242 RSVP recv Path 10.0.0.94->10.0.0.93 Len=272 ge-2/0/0.0 flags=0x1 ttl=255
Jun 25 18:32:31.941261 Integty Len 36 flag 0x0 key 0x00005e00000a seq 0xbf015059de530a00 digest 0x75c574bd 0x3c7e8ecb 0x435976f8 0x408b3263
Jun 25 18:32:31.941273 MessageID Len 12 Msg_ID: 878279 Epoch: 2641670 (Ack Desired)
Jun 25 18:32:31.941287 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:31.941299 Hop Len 12 10.0.0.94/0x80000009
Jun 25 18:32:31.941310 Time Len 8 30000 ms
Jun 25 18:32:31.941328 SrcRoute Len 28 10.0.0.93 S 10.0.0.41 S 10.0.0.170 S
Jun 25 18:32:31.941338 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:31.941349 Properties Len 12 Primary path
Jun 25 18:32:31.941359 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:31.941372 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:31.941393 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:31.941405 ADspec Len 48 MTU 1500
Jun 25 18:32:31.941417 RecRoute Len 12 10.0.0.94

Jun 25 18:32:31.943251 RSVP send Path 10.198.123.205->10.198.123.100 Len=272 so-2/1/0.1 flags=0x1 ttl=254
Jun 25 18:32:31.943266 Integty Len 36 flag 0x0 key 0x00002a00000a seq 0xbf0150594b670e00 digest 0xc5bc0316 0x87716529 0xf2ca9320 0xd0fdd978
Jun 25 18:32:31.943277 MessageID Len 12 Msg_ID: 211 Epoch: 11650457 (Ack Desired)
Jun 25 18:32:31.943290 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:31.943303 Hop Len 12 10.0.0.42/0x80000003
Jun 25 18:32:31.943313 Time Len 8 30000 ms
Jun 25 18:32:31.943328 SrcRoute Len 20 10.0.0.41 S 10.0.0.170 S
Jun 25 18:32:31.943338 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:31.943349 Properties Len 12 Primary path
Jun 25 18:32:31.943359 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:31.943372 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:31.943390 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:31.943402 ADspec Len 48 MTU 1500
Jun 25 18:32:31.943416 RecRoute Len 20 10.0.0.42 10.0.0.94

M320:

Jun 25 18:32:32.029412 RSVP recv Path 10.0.0.42->10.0.0.41 Len=272 so-0/3/0.1
Jun 25 18:32:32.029465 Integty Len 36 flag 0x0 key 0x00002a00000a seq 0xbf0150594b670e00 digest 0xc5bc0316 0x87716529 0xf2ca9320 0xd0fdd978
Jun 25 18:32:32.029477 MessageID Len 12 Msg_ID: 211 Epoch: 11650457 (Ack Desired)
Jun 25 18:32:32.029488 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.029498 Hop Len 12 10.0.0.42/0x80000003
Jun 25 18:32:32.029506 Time Len 8 30000 ms
Jun 25 18:32:32.029519 SrcRoute Len 20 10.0.0.41 S 10.0.0.170 S
Jun 25 18:32:32.029527 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:32.029537 Properties Len 12 Primary path
Jun 25 18:32:32.029547 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:32.029556 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.029580 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.029590 ADspec Len 48 MTU 1500
Jun 25 18:32:32.029600 RecRoute Len 20 10.0.0.42 10.0.0.94

Jun 25 18:32:32.031527 RSVP send Path 10.198.123.205->10.198.123.100 Len=272 ge-1/3/3.0
Jun 25 18:32:32.031541 Integty Len 36 flag 0x0 key 0x0000a900000a seq 0xbf015059f47d0a00 digest 0xbb579467 0x457e455a 0x915f3fa4 0x6eeb2319
Jun 25 18:32:32.031550 MessageID Len 12 Msg_ID: 5484 Epoch: 8616743 (Ack Desired)
Jun 25 18:32:32.031560 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.031569 Hop Len 12 10.0.0.169/0x091a536c
Jun 25 18:32:32.031577 Time Len 8 30000 ms
Jun 25 18:32:32.031586 SrcRoute Len 12 10.0.0.170 S
Jun 25 18:32:32.031594 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:32.031603 Properties Len 12 Primary path
Jun 25 18:32:32.031652 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:32.031662 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.031676 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.031686 ADspec Len 48 MTU 1500
Jun 25 18:32:32.031697 RecRoute Len 28 10.0.0.169 10.0.0.42 10.0.0.94

MX104:

Jun 25 18:32:32.149670 RSVP recv Path 10.0.0.169->10.0.0.170 Len=272 ge-0/0/1.0 flags=0x1 ttl=253
Jun 25 18:32:32.149787 Integty Len 36 flag 0x0 key 0x00000a0000a9 seq 0x595001bf000a7df4 digest 0x679457bb 0x5a457e45 0xa43f5f91 0x1923eb6e
Jun 25 18:32:32.149813 MessageID Len 12 Msg_ID: 5484 Epoch: 8616743 (Ack Desired)
Jun 25 18:32:32.149840 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.149867 Hop Len 12 10.0.0.169/0x091a536c
Jun 25 18:32:32.149891 Time Len 8 30000 ms
Jun 25 18:32:32.149918 SrcRoute Len 12 10.0.0.170 S
Jun 25 18:32:32.149943 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:32.149968 Properties Len 12 Primary path
Jun 25 18:32:32.149993 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:32.150018 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.150069 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.150094 ADspec Len 48 MTU 1500
Jun 25 18:32:32.150121 RecRoute Len 28 10.0.0.169 10.0.0.42 10.0.0.94

 

RESV Messages

Once MX104 has received Path message, it will generate the RESV message containing the MPLS Label value towards its next-hop.

MX104:

Jun 25 18:32:32.151356 RSVP send Resv 10.0.0.170->10.0.0.169 Len=168 ge-0/0/1.0 flags=0x1 ttl=255
Jun 25 18:32:32.151402 Integty Len 36 flag 0x0 key 0x00000a0000aa seq 0x595001c00001e237 digest 0x2f64cc8a 0x402a4baf 0xbd34ce62 0x9436192e
Jun 25 18:32:32.151427 MessageID Len 12 Msg_ID: 1121 Epoch: 1236180 (Ack Desired)
Jun 25 18:32:32.151453 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.151479 Hop Len 12 10.0.0.170/0x091a536c
Jun 25 18:32:32.151503 Time Len 8 30000 ms
Jun 25 18:32:32.151527 Style Len 8 FF
Jun 25 18:32:32.151575 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.151600 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.151624 Label Len 8 301456
Jun 25 18:32:32.151650 RecRoute Len 12 10.0.0.170

M320:

Jun 25 18:32:32.235459 RSVP recv Resv 10.0.0.170->10.0.0.169 Len=168 ge-1/3/3.0
Jun 25 18:32:32.235476 Integty Len 36 flag 0x0 key 0x0000aa00000a seq 0xc001505937e20100 digest 0x8acc642f 0xaf4b2a40 0x62ce34bd 0x2e193694
Jun 25 18:32:32.235486 MessageID Len 12 Msg_ID: 1121 Epoch: 1236180 (Ack Desired)
Jun 25 18:32:32.235496 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.235506 Hop Len 12 10.0.0.170/0x091a536c
Jun 25 18:32:32.235514 Time Len 8 30000 ms
Jun 25 18:32:32.235523 Style Len 8 FF
Jun 25 18:32:32.235537 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.235547 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.235556 Label Len 8 301456
Jun 25 18:32:32.235565 RecRoute Len 12 10.0.0.170
Jun 25 18:32:32.235669 RSVP new resv state, session 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0

Jun 25 18:32:32.240512 RSVP send Resv 10.0.0.41->10.0.0.42 Len=176 so-0/3/0.1
Jun 25 18:32:32.240530 Integty Len 36 flag 0x0 key 0x00002900000a seq 0xbf01505945ae0d00 digest 0xa61d34f1 0x42d26c8a 0x33b66d12 0xdd26b232
Jun 25 18:32:32.240540 MessageID Len 12 Msg_ID: 5485 Epoch: 8616743 (Ack Desired)
Jun 25 18:32:32.240551 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.240561 Hop Len 12 10.0.0.41/0x80000003
Jun 25 18:32:32.240569 Time Len 8 30000 ms
Jun 25 18:32:32.240577 Style Len 8 FF
Jun 25 18:32:32.240598 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.240608 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.240617 Label Len 8 315600
Jun 25 18:32:32.240629 RecRoute Len 20 10.0.0.41 10.0.0.170

M120:

Jun 25 18:32:32.357134 RSVP recv Resv 10.0.0.41->10.0.0.42 Len=176 so-2/1/0.1 flags=0x1 ttl=255
Jun 25 18:32:32.357151 Integty Len 36 flag 0x0 key 0x00002900000a seq 0xbf01505945ae0d00 digest 0xa61d34f1 0x42d26c8a 0x33b66d12 0xdd26b232
Jun 25 18:32:32.357162 MessageID Len 12 Msg_ID: 5485 Epoch: 8616743 (Ack Desired)
Jun 25 18:32:32.357177 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.357190 Hop Len 12 10.0.0.41/0x80000003
Jun 25 18:32:32.357200 Time Len 8 30000 ms
Jun 25 18:32:32.357210 Style Len 8 FF
Jun 25 18:32:32.357235 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.357249 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.357259 Label Len 8 315600
Jun 25 18:32:32.357274 RecRoute Len 20 10.0.0.41 10.0.0.170

Jun 25 18:32:32.379175 RSVP send Resv 10.0.0.93->10.0.0.94 Len=184 ge-2/0/0.0 flags=0x1 ttl=255
Jun 25 18:32:32.379194 Integty Len 36 flag 0x0 key 0x00005d00000a seq 0xc0015059ddcb0500 digest 0x123882a6 0xc852ee76 0x2564233e 0x68cb222c
Jun 25 18:32:32.379206 MessageID Len 12 Msg_ID: 212 Epoch: 11650457 (Ack Desired)
Jun 25 18:32:32.379220 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.379233 Hop Len 12 10.0.0.93/0x80000009
Jun 25 18:32:32.379244 Time Len 8 30000 ms
Jun 25 18:32:32.379253 Style Len 8 FF
Jun 25 18:32:32.379281 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.379326 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.379338 Label Len 8 301728
Jun 25 18:32:32.379356 RecRoute Len 28 10.0.0.93 10.0.0.41 10.0.0.170

MX960:

Jun 25 18:32:32.465718 RSVP recv Resv 10.0.0.93->10.0.0.94 Len=184 ge-1/1/7.0 flags=0x1 ttl=255
Jun 25 18:32:32.465736 Integty Len 36 flag 0x0 key 0x00005d00000a seq 0xc0015059ddcb0500 digest 0x123882a6 0xc852ee76 0x2564233e 0x68cb222c
Jun 25 18:32:32.465750 MessageID Len 12 Msg_ID: 212 Epoch: 11650457 (Ack Desired)
Jun 25 18:32:32.465767 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.465785 Hop Len 12 10.0.0.93/0x80000009
Jun 25 18:32:32.465798 Time Len 8 30000 ms
Jun 25 18:32:32.465811 Style Len 8 FF
Jun 25 18:32:32.465841 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.465856 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.465869 Label Len 8 301728
Jun 25 18:32:32.465890 RecRoute Len 28 10.0.0.93 10.0.0.41 10.0.0.170

re1.bentley> show rsvp session name TEST-MX960-MX104 detail
Ingress RSVP: 30 sessions
10.198.123.100
 From: 10.198.123.205, LSPstate: Up, ActiveRoute: 0
 LSPname: TEST-MX960-MX104, LSPpath: Primary
 LSPtype: Static Configured
 Suggested label received: -, Suggested label sent: -
 Recovery label received: -, Recovery label sent: 301728
 Resv style: 1 FF, Label in: -, Label out: 301728
 Time left: -, Since: Sun Jun 25 18:32:31 2017
 Tspec: rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
 Port number: sender 1 receiver 44394 protocol 0
 PATH rcvfrom: localclient
 Adspec: sent MTU 1500
 Path MTU: received 1500
 PATH sentto: 10.0.0.93 (ge-1/1/7.0) 3 pkts
 RESV rcvfrom: 10.0.0.93 (ge-1/1/7.0) 1 pkts, Entropy label: No
 Explct route: 10.0.0.93 10.0.0.41 10.0.0.170
 Record route: <self> 10.0.0.93 10.0.0.41 10.0.0.170
Total 1 displayed, Up 1, Down 0

As this service was part of L2VPN CCC configuration, hence no explicit null label was sent by penultimate hop router resulting in label sent to MX960 PE.

xe-2/0/0.601 (1 entry, 1 announced)

TSI:

KRT in-kernel xe-2/0/0.601.0      /32 -> {Push 301728}

*CCC    Preference: 200/1

Next hop type: Router, Next hop index: 1255

Address: 0xa5dba0c

Next-hop reference count: 2

Next hop: 10.0.0.93 via ge-1/1/7.0 weight 0x1, selected

Label-switched-path TEST-MX960-MX104

Label operation: Push 301728

Label TTL action: no-prop-ttl

Load balance label: Label 301728: None;

Label element ptr: 0xa7cc2c0

Label parent element ptr: 0x0

Label element references: 3

Label element child references: 0

Label element lsp id: 0

Session Id: 0xbcf

State: <Active Int>

Local AS: 65004

Age: 10:45      Metric: 425

Validation State: unverified

Task: MPLS global

Announcement bits (1): 1-KRT

AS path: I

So that’s all for RSVP in Junos. I hope you liked the blog and let me know if there are any queries.

Mohit Mittal