Hi All
Please see my Github link for Junos-automation examples which should be very handy in your environment i.e production and testing/integration. Let me know if there are any particular examples you would like me to share with you.
Thanks
Mohit
Juniper Config Backup on GITLAB
Hi All
In this blog, we will see how we can take the backup of router configs and push it to gitlab for version control.
We will take Juniper routers here for example and build the script in Python and run our task as a cronjob on CentOS 7 to automatically backup the configs onto GITLAB.
We will use power of Git here to store the differentials in configs and we can see the differences in Gitlab UI.
So let’s see how we can achieve it.
Before starting with config backup, let’s build the device store on which we will be running the script or in other words backup will be running. For this we are storing the values in YAML file http://yaml.org/ as dictionary. You can either store the values as list or Dictionary in YAML. You can use json also to store the same data instead of YAML.
Yaml file (.yml) --- # Add devices here in form Hostname: 'ip address'
Manchester_MX10003: '10.198.206.3' Glasgow_MX10003: '10.198.206.6' London_MX104: '10.198.206.9' Leeds_MX104: '10.198.206.12' Bristol_MX104: '10.198.206.15'
Above are the file contents, where we are storing the data as Key, Value pair where Key is hostname of device and Values are its IP Addresses.
Now our data store is done, we can start with Juniper PYez (https://www.juniper.net/documentation/en_US/junos-pyez/topics/concept/junos-pyez-overview.html) to get the configs first.
We will be importing the Pyez modules, set the .yml input file location and run ‘for’ loop on our dictionary. We will store the backup config files as .txt file with hostnames as Title for easy accessibility. Don’t forget to import yaml module as we will be working on yaml file.
from jnpr.junos import Device
from jnpr.junos.exception import ConnectError
import yaml
input_file = '/home/sun/gitlab/device_list.yml'
for key, value in yaml.load(open(input_file)).items():
dev_username = test
dev_password = test
dev = Device(host=value, user=dev_username, passwd=dev_password, port='830')
try:
dev.open()
except ConnectError as err:
print ("Cannot connect to device: {0}".format(err))
sys.exit(1)
except Exception as err:
print (err)
sys.exit(1)
config = str(dev.cli("show configuration | no-more", warning=False))
#####Create/Write to Config to File
file_name = key + '.txt'
dev.close()
That was pretty simple. Let me know if you have any issues. Now let’s work out how to push it to GIT.
We will be using the subprocess module to do this work for us where we will be running series of commands in serial to put the files across the gitlab. You are starting by going into particular directory which is your starting git project directory. You are looking at each branch within your git project using ‘git branch’ command and then checking out a particular branch on which you to work or store the data. In our case it’s Core_Network. Once you have moved to that, you can move into other specific folders and ‘mv’ your backup .txt files into this folder.
Once that is done, you will use git commands, like ‘git add –all’ to add all files as part of staging. ‘git commit –m “some description”’ to commit the files and then use ‘git push’ to push them to remote gitlab server.
Code will be:
from subprocess import PIPE from subprocess import Popen import sys import os import yaml
cmds =['cd /home/sun/gitlab/athena-test', 'git branch', 'ls -l', 'git checkout " Core_Network"', 'cd "Core Network"', 'cd "Device backups"', 'mv /home/sun/gitlab/*.txt /home/sun/gitlab/athena-test/"Core Network"/"Device backups"/', 'git add --all', 'git commit -m "Updated config files"', 'git push' ]
encoding = 'utf8'
p = Popen('/bin/sh', stdin=PIPE, stdout=PIPE, stderr=PIPE)
for cmd in cmds:
p.stdin.write(cmd + "\n")
p.stdin.close()
#print p.stdout.read()
print "Push to GitLab Completed"
One main thing you have to keep in mind is that you won’t be able to push the files until unless you have some remote servers configured under your server.
For example, mine is below where I have removed certain values and replaced them with xxx, yyy and ip address.. xxx is username, yyy is password and hostname is gitlab server address.
sun@ $ git remote -v origin https://xxx:yyy@<hostname>/athena-test.git (fetch) origin https://xxx:yyy@<hostname>/athena-test.git (push)
Let’s see this in action by changing the config on one of the router.
write@re0.Manchester.MX10003.uk> edit Entering configuration mode write@re0.Manchester.MX10003.uk# run show configuration system services ssh root-login allow; protocol-version v2; max-sessions-per-connection 32; connection-limit 20; rate-limit 10; [edit] write@re0.Manchester.MX10003.uk# set system services ssh connection-limit 10 [edit] write@re0.Manchester.MX10003.uk# show | compare [edit system services ssh] - connection-limit 20; + connection-limit 10; [edit] write@re0.Manchester.MX10003.uk# commit commit complete
Run the script now from CentOS Server
sun@ pwd /home/sun/gitlab sun@ $ python git_config_backup.py Successfully Collected Configuration from Device: Bristol_MX104 Successfully Collected Configuration from Device: Manchester_MX10003 Successfully Collected Configuration from Device: Glasgow_MX10003 Successfully Collected Configuration from Device: London_MX104 Successfully Collected Configuration from Device: Leeds_MX104 Push to GitLab Completed
You can see config was pushed and if we see the gitlab, it’s clearly showing the difference from the previous backup it had. Red one is one that is removed and Green one is what has been added.
So you can use this utility as version control of your configs and once you are happy with the configs you can push them to master for production use 🙂
One last thing, if you have to run this as a cronjob on Centos, just edit the crontab file using ‘crontab –e’ and add the path to the script and at what particular time you want to run and that’s all.
I hope you liked this blog. Let me know if you have any queries.
Regards
Mohit
Connecting OpendayLight to Juniper Routers via Netconf
Hi All
In this blog, we will look at configuring Juniper routers via Opendaylight which in turn uses netconf/restconf for making the connection.
Before we can start doing the configuration we need to create a Netconf connector between Opendaylight and Juniper routers. Also before that let’s first see what NETCONF is 🙂
Network Configuration Protocol (NETCONF) provides a mechanism to install, manipulate and delete the configuration of network devices. It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs).
OpenDaylight uses YANG modules to access the device via NETCONF and we can do config as well. In this post we will see how to configure ODL for NETCONF connections. This is tried method so please do this as listed and I have seen others methods may not work properly.
Below topology we will be using in this blog.
- Juniper MXs are running on 18.2R1 and 17.4R1
- OpendayLight Release is Oxygen 0.8.2
1) In First instance, you need to enable netconf on Juniper
write@Manchester> show configuration system services netconf
ssh {
connection-limit 10;
rate-limit 5;
}
rfc-compliant;
yang-compliant;
2) Download the 0.8.2 Oxygen Tar file from Opendaylight website and untar it.
Command “ tar –xvf karaf-0.8.2.tar.gz”
This will create a directory called karaf-0.8.2 in same directory structure.
[root@Opendaylight-2 sun]# ls -l | grep karaf-0.8.2 drwxr-xr-x. 13 root root 4096 Jul 26 15:42 karaf-0.8.2 -rw-rw-r--. 1 sun sun 358590049 Jul 24 13:46 karaf-0.8.2.tar.gz
3) Now create a file called, 99-netconf-connector.xml and paste the following contents in it
prefix:sal-netconf-connector
controller-config
10.198.206.3
830
write
write
false
true
http://xml.juniper.net/xnm/1.1/xnm?module=configuration&revision=2018-01-01
prefix:netty-event-executor
global-event-executor
prefix:binding-broker-osgi-registry
binding-osgi-broker
prefix:dom-broker-osgi-registry
dom-broker
prefix:netconf-client-dispatcher
global-netconf-dispatcher
prefix:threadpool
global-netconf-processing-executor
prefix:scheduled-threadpool
global-netconf-ssh-scheduled-executor
urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf?module=odl-sal-netconf-connector-cfg&revision=2015-08-03
You have to change the details for the values mentioned in Red above according to first device you are trying to add. Don’t change anything else. However if your Junos version is other than 18.2 then you need to check the revision number of yang modules and put the correct date for field in Green above.
Once done, save the file.
4) Now start the opendaylight using command:
[root@Opendaylight-2 sun]# ./karaf-0.8.2/bin/karaf
Apache Karaf starting up. Press Enter to open the shell now...
100% [========================================================================]
Karaf started in 18s. Bundle stats: 388 active, 389 total
________ ________ .__ .__ .__ __
\_____ \ ______ ____ ____ \______ \ _____ ___.__.| | |__| ____ | |___/ |_
/ | \\____ \_/ __ \ / \ | | \\__ \ > ___/| | \| ` \/ __ \\___ || |_| / /_/ > Y \ |
\_______ / __/ \___ >___| /_______ (____ / ____||____/__\___ /|___| /__|
\/|__| \/ \/ \/ \/\/ /_____/ \/
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown OpenDaylight.
opendaylight-user@root>
Install following packages, you don’t have to add any other at this moment of time:
feature:install odl-netconf-topology odl-restconf odl-netconf-connector-all
After installing, copy the file 99-netconf-connector.xml created above under directory karaf-0.8.2/etc/opendaylight/karaf/
cp 99-netconf-connector.xml karaf-0.8.2/etc/opendaylight/karaf/
5) After this, using POSTMAN or similar application, send a PUT request to following URL
PUT http://<CONTROLLER-IP-ADDRESS:8181>/restconf/config/network-topology:network-topology/topology/topology-netconf/node/<node-name>
Same as before change the values in Red and Green accordingly for your case.
node-name 10.198.206.3 830 write write false 0 http://xml.juniper.net/xnm/1.1/xnm?module=junos-common-types&revision=2018-01-01 http://xml.juniper.net/xnm/1.1/xnm?module=module=junos-conf-root&revision=2018-01-01
6) After this restart the opendaylight
opendaylight-user@root>system:shutdown Confirm: halt instance root (yes/no): yes opendaylight-user@root> [root@Opendaylight-2 sun]# ./karaf-0.8.2/bin/karaf Apache Karaf starting up. Press Enter to open the shell now... opendaylight-user@root>
At this point you should some messages like as mentioned in Karaf_Logs after adding the netconf-connector. Let it run..it may take 10-20 minutes from here which is basically ODL is pulling all the Juniper Yang modules in its cache/schema folder.
Once that is done you should see the below message in karaf log which you can see using log:tail from opendaylight shell prompt.
| INFO | sing-executor-22 | NetconfDevice | 304 - org.opendaylight.netconf.sal-netconf-connector - 1.7.2 | RemoteDevice{Manchester}: Netconf connector initialized successfully
Once you get the message, your node has been mounted which you can check using GET request at following URL
GET http:// <CONTROLLER-IP-ADDRESS:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/<Node-name>/yang-ext:mount/
Now its ready to configure 🙂
Let’s configure a sample L3VPN using this
See the snapshot which is basically a PUT request with XML payload
Lets’s verify
write@Manchester> show configuration routing-instances odl-test
instance-type vrf;
interface xe-0/2/0.4000;
route-distinguisher 10.198.206.41:4000;
vrf-target target:2856:4000;
vrf-table-label;
routing-options {
multipath;
protect core;
}
protocols {
bgp {
group ebgp {
type external;
peer-as 65101;
as-override;
neighbor 7.7.7.7 {
authentication-key "$9$CuyoAORhclMLNylJDkP3nylKvWx"; ## SECRET-DATA
bfd-liveness-detection {
minimum-interval 100;
multiplier 3;
}
}
}
}
}
Here you go.. its working 🙂
That’s all for today.. I will do a separate blog for other service configurations via ODL. Let me know if you have any questions.
Bbye
Mohit
Segment Routed L2VPN TE – Cisco IOS-XR
Hi All
Let’s see Segment routing in action in this blog particularly on IOS-XR. Segment routing is quite new concept which is picking pace these days. In my earlier blog I listed the differences between Segment routing and RSVP-TE and SR can replace it and there are certain areas where it may not be able to help however L3VPN and L2VPN Traffic Engineering is surely one area where it can be used and in this blog we will use SR as TE while configuring the L2VPN.
For this we will take NCS5508 as our router platform in below topology where we will configure the L2VPN SR-TE between NCS5508-1 to NCS5508-3 via NCS5508-8.
Let’s see the SR config first.
SR beauty is that there is no special protocol needed to run it. SR Labels will be advertised in OSPF/ISIS and these protocols have been uplifted to carry them. SR Labels are carried in Type 10 Opaque area LSA as TLV.
If you are familiar with OSPF config in IOS-XR, most of the config below looks similar to you as we have just enabled OSPF under area0 and added interfaces under it.
However there are 3 configs highlighted in RED which we have enabled for Segment routing.
RP/0/RP0/CPU0:ncs5508-1#show running-config router ospf router ospf 1 nsr distribute link-state segment-routing mpls nsf ietf segment-routing sr-prefer area 0 mpls traffic-eng interface Loopback0 passive enable prefix-sid index 1 explicit-null ! interface HundredGigE0/1/0/0 cost 1 network point-to-point ! interface FortyGigE0/2/0/8 cost 4 network point-to-point ! interface FortyGigE0/2/0/10 cost 4 network point-to-point ! interface FortyGigE0/2/0/18 cost 4 network point-to-point ! ! mpls traffic-eng router-id Loopback0 !
segment-routing mpls , this command causes OSPF to originate RI LSA, Extended Prefix and Extended Link LSAs. It enables MPLS on all interfaces in area(s) enabled for SR and programs SR MPLS labels for forwarding.
segment-routing sr-prefer is used to set the preference of segment routing (SR) labels over label distribution protocol (LDP) labels in case both are available towards destination in your network.
prefix-sid index 1 explicit-null — A prefix SID is associated with an IP prefix. The prefix SID is manually configured from the segment routing global block (SRGB) range of labels. The prefix segment steers the traffic along the shortest path to its destination. A node SID is a special type of prefix SID that identifies a specific node. It is configured under the loopback interface with the loopback address of the node as the prefix. The prefix SID is globally unique within the segment routing domain.
Let’s verify it
RP/0/RP0/CPU0:ncs5508-1#show ospf sid-database SID Database for ospf 1 with ID 192.168.0.1 SID Prefix/Mask -------- ------------------ 1 192.168.0.1/32 (L) 2 192.168.0.2/32 3 192.168.0.3/32 4 192.168.0.4/32 5 192.168.0.5/32 6 192.168.0.6/32 7 192.168.0.7/32 8 192.168.0.8/32
In the same way we have configured the Node-SID as same index as last octet on lo0 interface.
RP/0/RP0/CPU0:ncs5508-1#show ospf database opaque-area 192.168.0.1/32 OSPF Router with ID (192.168.0.1) (Process ID 1) Type-10 Opaque Link Area Link States (Area 0)
LS age: 782 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 7.0.0.1 Opaque Type: 7 Opaque ID: 1 Advertising Router: 192.168.0.1 LS Seq Number: 800006fa Checksum: 0xed8b Length: 44 Extended Prefix TLV: Length: 20 Route-type: 1 AF : 0 Flags : 0x40 Prefix : 192.168.0.1/32 SID sub-TLV: Length: 8 Flags : 0x50 MTID : 0 Algo : 0 SID Index : 1
RP/0/RP0/CPU0:ncs5508-1#show mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
—— ———– —————— ———— ————— ————
16002 Exp-Null-v4 SR Pfx (idx 2) Hu0/1/0/0 50.50.50.30 0
16003 16003 SR Pfx (idx 3) Hu0/1/0/0 50.50.50.30 0
16004 Exp-Null-v4 SR Pfx (idx 4) Fo0/2/0/8 50.50.50.25 0
16005 16005 SR Pfx (idx 5) Fo0/2/0/8 50.50.50.25 6421133
16006 16006 SR Pfx (idx 6) Hu0/1/0/0 50.50.50.30 0
16006 SR Pfx (idx 6) Fo0/2/0/8 50.50.50.25 0
16007 16007 SR Pfx (idx 7) Hu0/1/0/0 50.50.50.30 0
16008 Exp-Null-v4 SR Pfx (idx 8) Fo0/2/0/18 50.50.50.38 0
Now let’s create a Segment routed TE EVPN based P2P L2 Circuit. 🙂
Ideally we know that Controller is needed to play with Segment routed labels and Controller can insert the appropriate labels required for TE however if you don’t have Controller, you can configure the path by explicitly giving the path through which traffic will be going.
So we will start with l2vpn xconnect taking edge interface on NCS5508-1 and assigning a EVPN EVI 1100 with source and target ac-id (attachment circuit id) and associate it with pw-class which we will define in next step.
RP/0/RP0/CPU0:ncs5508-1#show running-config l2vpn xconnect group evpn-vpws p2p vpws1 l2vpn xconnect group evpn-vpws p2p vpws1 interface HundredGigE0/2/0/2.1100 neighbor evpn evi 1100 target 11003 source 11001 pw-class vpws1-class ! ! ! !
Pw-class is associated with sr-te policy to steer traffic through the network. An SR-TE policy path is expressed as a list of segments that specifies the path, called a segment ID (SID) list. Each segment is an end-to-end path from the source to the destination, and instructs the routers in the network to follow the specified path instead of the shortest path calculated by the IGP
RP/0/RP0/CPU0:ncs5508-1#show running-config l2vpn pw-class vpws1-class l2vpn pw-class vpws1-class encapsulation mpls preferred-path sr-te policy vpws1-policy ! ! !
RP/0/RP0/CPU0:ncs5508-1#show running-config segment-routing traffic-eng policy vpws1-policy segment-routing traffic-eng policy vpws1-policy color 10 end-point ipv4 192.168.0.3 candidate-paths preference 200 dynamic metric type te ! ! ! preference 300 explicit segment-list vpws1-path ! ! ! ! ! !
So in our policy, we have defined one preferred path which is dynamic and if that fails it should failover to explicitly configured segment list defined via path vpws1-path.
RP/0/RP0/CPU0:ncs5508-1#show running-config segment-routing traffic-eng segment-list vpws1-path segment-routing traffic-eng segment-list vpws1-path index 10 address ipv4 50.50.50.38 index 20 address ipv4 50.50.50.21 ! ! !
So if we see currently the route towards NCS5508-3, it’s going via IGP Route and not taking our defined list which is expected.
RP/0/RP0/CPU0:ncs5508-1#show route 192.168.0.3 Wed Jun 27 14:49:59.487 UTC
Routing entry for 192.168.0.3/32 Known via "ospf 1", distance 110, metric 3, labeled SR, type intra area Installed Jun 27 14:47:18.930 for 00:02:40 Routing Descriptor Blocks 50.50.50.30, from 192.168.0.3, via HundredGigE0/1/0/0 Route metric is 3 No advertising protos.
So let’s see our L2VPN status.
RP/0/RP0/CPU0:ncs5508-1#show l2vpn xconnect group evpn-vpws detail
Group evpn-vpws, XC vpws1, state is up; Interworking none AC: HundredGigE0/2/0/2.1100, state is up Type VLAN; Num Ranges: 1 Rewrite Tags: [] VLAN ranges: [1100, 1100] MTU 9016; XC ID 0x1000001; interworking none Statistics: packets: received 157064234, sent 157063216 bytes: received 234968088320, sent 234966565392 drops: illegal VLAN 0, illegal length 0 EVPN: neighbor 192.168.0.3, PW ID: evi 1100, ac-id 11003, state is up ( established ) XC ID 0xc0000001 Encapsulation MPLS Source address 192.168.0.1 Encap type Ethernet, control word disabled Sequencing not set Preferred path Active : SR TE vpws1-policy, Statically configured, fallback enabled Tunnel : Up EVPN Local Remote ------------ ------------------------------ ----------------------------- Label 64007 64006 MTU 9016 9016 Control word disabled disabled AC ID 11001 11003 EVPN type Ethernet Ethernet
So if we go n shut the primary dynamic path we can see the forwarding table moves over to our segment-list defined for label 16003 which is for NCS5508-3.
RP/0/RP0/CPU0:ncs5508-1#config t Wed Jun 27 14:58:04.096 UTC RP/0/RP0/CPU0:ncs5508-1(config)#int HundredGigE0/1/0/0 RP/0/RP0/CPU0:ncs5508-1(config-if)#shutdown RP/0/RP0/CPU0:ncs5508-1(config-if)#commit
RP/0/RP0/CPU0:ncs5508-1#show mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16002 16002 SR Pfx (idx 2) Fo0/2/0/18 50.50.50.38 0
16003 16003 SR Pfx (idx 3) Fo0/2/0/18 50.50.50.38 0
So thats all, i hope you like the blog and let me know your feedback.
Regards
Mohit
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.
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
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
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
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:
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
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.
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.
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
