Tag Archives: TCP/IP

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

Advertisements

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

DHCP Server on Juniper MX104

In this blog, we will discuss about configuration of DHCP for IPv4 on Junos particularly for MX104. MX router will act as a DHCP Local server which will assign IP Addresses to clients from the DHCP pool configured.

To configure DHCP as local server we need to apply the following license on MX which is paid license over the top.

subscriber-address-assignment – Radius/SRC Address Pool Assignment

subscriber-ip   – Dynamic and Static IP

For those who doesn’t want to buy license, they have option of configuring the DHCP as relay however for which server will be external and not internal.

With this blog, we will look at configuration of router acting as DHCP server. Relay configuration is not part of this current blog.

Below model topology will be used where clients (Windows Laptop) is connected to MX104 PE via switch. VRRP is configured with MX104 CE-1 and MX104 CE-2 and both are acting as DHCP Server, however we will be looking at configuration of MX104 CE-1 as same configuration needs to be configured on both.

MX104 PE is connected to MX960 PE over L2VPN which is just extending the L2 domain from client over to DHCP server.

DHCP Model

Ok Lets start by looking at Interface configuration on MX104-CE-1 where xe-2/0/3 link is connected to EX4550 switch and VRRP is running with VRRP VIP as 50.50.50.1 and address on logical interface is 50.50.50.101.

Nothing special till here and no DHCP configuration even.

MX104-CE-1> show configuration logical-systems LS2-CLMB interfaces xe-2/0/3
unit 601 {
 vlan-id 601;
 family inet {
 address 50.50.50.101/24 {
 vrrp-group 201 {
 virtual-address 50.50.50.1;
 priority 200;
 accept-data;
 track {
 route 0.0.0.0/0 routing-instance default priority-cost 101;
 }
 }
 }
 }
}

Ok now lets add DHCP configuration by defining the dhcp-local server under system services hierarchy.

Here we need to define the group with any arbitrary name and interface which will be participating in DHCP msg exchange.

system {
 services {
 dhcp-local-server {
 group dhcp {
 interface xe-2/0/3.601;
 }
 }
 }
}

Once dhcp server has been defined, we will configure DHCP pools to provide addresses to clients.

In same heirachy we can define the dhcp-attributes like lease time, DNS servers and router which suggests the ip address of router in the subnetwork. We have 2 routers providing the DHCP services however as its under VRRP it will be better to give just one address which will be VRRP VIP. In this way in case of any issues on CE-1, VIP will move over to CE-2 and it will be able to assign the addresses.

Range is defined as ip addresses which DHCP server will assign. Lease time is 24 hours in seconds i.e 86400

access {
 address-assignment {
 pool dhcp {
 family inet {
 network 50.50.50.0/24;
 range dhcp {
 low 50.50.50.4;
 high 50.50.50.100;
 }
 dhcp-attributes {
 maximum-lease-time 86400;
 name-server {
 8.8.8.8;
 }
 router {
 50.50.50.1;
 }
 }
 }
 }
 }
}

Once everything is done, as soon as Laptop comes online it will send the request and MX104 will assign the ip address. We will see the messages in just a while but one thing to note is that if you have protect-RE firewall filter configured on loopback0 interface of MX104, it is essential to allow bootps and bootpc messages

term dhcp {
from {
 protocol udp;
 port [ bootpc bootps ];
}
then accept;
}

MX104_CE-1> show dhcp server binding logical-system LS2-CLMB
IP address Session Id Hardware address  Expires State Interface
50.50.50.5 2          68:f7:28:45:14:91 85495   BOUND xe-2/0/3.601

As you can see above, 50.50.50.5 address has been assigned by MX104 and state is BOUND and also listing the hardware address of client machine.

Now lets see how DHCP messages flow. I have shown below the snapshots of wireshark capture for the DHCP messages.

As soon as Laptop comes online or it is connected to LAN, first message it sent is DHCP discover message which is basically a broadcast BOOTP message with frame field as its own mac address as source and all FFs as destination MAC. UDP port number is 68 with destination as 67 so it is basically looks like

UDP 0.0.0.0:68 -> 255.255.255.255:67

As client doesn’t have IP address at this time, it uses 0.0.0.0 as src ip.

68 is standard UDP port assigned for bootp client and 67 for bootp server.

DHCP_1

Once client broadcasts the DHCP discover request, DHCP server sends a DHCP Offer. Src IP Address is physical IP of router which is currently holding the VIP in VRRP case. In our case its MX104 CE-1.

Offer will contain the IP Address 50.50.50.5 as we have already seen in CLI output above along with other parameters which we configured like Lease time, Subnet Mask, Router address, DNS Server etc etc.

DHCP_2

After receiving the Offer and before accepting it, client again sends the broadcast message by including the IP 50.50.50.5 for confirmation.

DHCP_3

At this point, DHCP server sends unicast acknowledgment for it to keep the address and connection is complete.

DHCP Client will periodically sends DHCP Inform messages (both Unicast and Broadcast) to let others know of the address being used.

DHCP_4

Ok so that’s all for DHCP, i hope you liked the post and let me know if you have any feedback or queries.

Mohit Mittal

 

ARP, InARP, RARP, Proxy ARP & Gratuitous ARP?? Whats this all about!!

There are lots of Arp terms in Network field today i.e. ARP, RARP, InARP, Proxy ARP and Gratuitous ARP. This was really confusing for me atleast in my early networking days and I am sure people who are new to networking must be in same situation. So I thought of putting the details here in order to alleviate their confusion. So let’s start

 1) ARP (Address Resolution Protocol)

ARP or Address Resolution protocol is a protocol as its name states which works on TCP/IP Layer 2. Networking between devices can’t be done without using this protocol which basically helps in getting the mac-address of connected router or gateway from IP Address. So for example, host/computer is connected to Router over Ethernet and we have manually configured IP Addresses on both sides with Router acting as Gateway for Host computer. Before Host can send packet to Router, it needs to build Layer 2 Frame and this frame encapsulates Packet including Payload/Date. You know that Frame has Source MAC-Address and Destination MAC-Address fields apart from other fields. So host can take out source-mac address from value burned in its NIC (Network Interface card) however it won’t be knowing the destination mac-address and in order to get the value of destination mac address host uses ARP. So Host will send broadcast ARP request message (destination FF:FF:FF:FF:FF:FF MAC address), which is accepted by all computers, requesting an answer for router’s gateway mac-address which is returned by Router in form for Arp-reply as a unicast.

APR_Packet Format

54:1e:56:f7:7d:4a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 602, p 0, ethertype ARP, arp who-has 20.20.20.20 tell 20.20.20.200

00:00:00:5e:00:00 > 54:1e:56:f7:7d:4a, ethertype 802.1Q (0x8100), length 64: vlan 602, p 0, ethertype ARP, arp reply 20.20.20.20 is-at 00:00:00:5e:00:00

2) InARP ( Inverse ARP)

Now what is Inverse Arp then? Inverse ARP as you might guess is the opposite of ARP.  Instead of using layer 3 IP address to find a layer 2 MAC address, Inverse ARP uses layer 2 MAC addresses to find a layer 3 IP address.

Inverse ARP was mostly used by Framerelay and ATM Networks to map the DLCI to IP Address. So router basically asks the IP Address of destination or other end of PVC by listing DLCI for that router.

3) RARP (Reverse ARP)

Reverse ARP is same as Inverse ARP however it was mainly used for device configuration. In InARP IP Address of remote end was being asked however RARP task is to get the IP Address for its own purpose.

A network administrator creates a table in a local area network’s gateway router that maps the physical machine (or Media Access Control – MAC address) addresses to corresponding IP Addresses. When a new machine is set up, its RARP client program requests it’s IP Address from the gateway router. Assuming that an entry has been set up in the router table, the RARP server will return the IP address to the machine which can store it for future use.

Reverse ARP has been deprecated and replaced by BOOTP which was then later replaced by DHCP.

4) Proxy ARP

As we mentioned above that the ARP is basically to find out Layer 2 address from Layer 3 IP Address. Now suppose host is connected to router over Ethernet and host has one address 10.10.0.1/16 and router has 10.10.10.0/24.

Host wants to resolve the ARP for 10.10.0.100 and thinks that Router is also in same subnet so should be able to get the mac-address however as Routers by design limit broadcast domains so won’t be sending the arp reply back and request will be rejected. If on the other hand router has any other interface connected to 10.10.0.0/16 network and proxy-arp is enabled, in that case Router will send the arp reply to host by listing its own mac-address basically acting as proxy for destination Network. In this case we don’t have to change the netmask of host and it will work fine.

On Cisco interfaces, when we configure “no ip proxy-arp”, we are disabling this behaviour.

5) Gratuitous ARP

Gratuitous ARP is by far the interesting version of ARP and lets see how gratuitous ARP works. We will go through 2 use cases here:

Firstly let’s discuss some of the properties of GARP

  • Both source and destination IP in the packet are the IP of the host issuing the gratuitous ARP
  • The destination MAC address is the broadcast MAC address (ff:ff:ff:ff:ff:ff) . This means the packet will be flooded to all ports on a switch
  • No reply is expected

1st use case of GARP is finding duplicate IP Address on LAN. Host which wakes up lets say after reboot sends GARP by putting the Sender IP address and Target IP Address as its own IP and broadcast the frame using Ethernet II destination address of all FFs.

It is not expecting any reply however if someone replies back with mac-address corresponding to Target IP Address then it means that IP address is being used somewhere else in LAN which is a problem. In this way host can detect duplicates.

2nd use case of GARP is case of redundancy protocols like VRRP/HSRP. VRRP (Virtual Redundancy Routing Protocol) or HSRP works by providing redundant physical gateways to host reachable over same Virtual address in order for Host to reach destination networks even though one physical router is down.

GARP_VRRP

VRRP has VIP (Virtual IP) concept which is shared among 2 VRRP routers and one of them is Active at any one time and holds Virtual MAC-Address corresponding to this VIP. Whenever host requests for ARP for 10.1.1.1, Master router will reply back with Virtual MAC Address.

Now we know that Switch updates its MAC Address table by looking at Mac address being learned on which port. Assuming Router 1 is Master currently, Switch will have entry in its table for Virtual Mac address learnt via Eth1 interface.

Let’s suppose that Router 1 goes down and in that case Router 2 sends GARP forcing switch to update its MAC-address table in order for it to update new location of Virtual MAC address reachable over new port i.e Eth2.

In this way, Host never sees an issue and packets sent by it will always egress a correct port.

Format of Gratuitous ARP

GARP Format

So that’s all, I hope you enjoyed this blog and I was able to clear some of your confusion. Let me know if you still have any doubt.

Thanks

Mohit Mittal