Category Archives: JNCIS

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

 

ODL-Netconf-Juniper1) 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://&lt;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/

GET-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

Send-L3VPN-Request

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

Advertisements

PCEP Initiated LSP using OpenDayLight and Juniper vMX

Hi All

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

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

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

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

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

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

Topology Diagram
Topology Diagram

 

We will divide the post into 3 parts.

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

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

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

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

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

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

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

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

feature:install odl-restconf odl-bgpcep-bgp

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

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

POST Request_BGP Router ID
POST Request_BGP Router ID

Then Configure the peer 192.168.71.24 with specific BGP Parameters and families

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

POST Request_BGP Peer
POST Request_BGP Peer

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

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

GET Request_BGP Peering
GET Request_BGP Peering

From VMX side:

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

 

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

Snippet below:

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

 

2) Now let’s configure the PCEP

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

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

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

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

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

Let’s see it from VMX-4

 

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

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

odl (main)
 Delegated : 0
 Externally provisioned : 0

From ODL side:

GET Request_PCEP Status
GET Request_PCEP Status

3)      PCEP Initiated LSP

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

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

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

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

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

 

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

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

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

 

Regards

Mohit

 

EVPN in JunOS

Hi All

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

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

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

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

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

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

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

EVPN
EVPN Topology

Let’s see config on Manchester Juniper PE router.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Same thing you can see in routing table as well.

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

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

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

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

 

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

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

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

You can see Ping works without any loss.

Ping

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

BBye 🙂

Mohit

Segment Routing v/s RSVP-TE?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

Juniper JunOS Command Series – 1

Hi All, from this series we will look at some useful JunOS commands and concepts where Juniper give us flexibility over other vendors and I hope this will help you in case you are switching from other vendor products to JunOS.

We will look at example from interface configuration however same can be applied to any stanza or part of configuration in Junos.

Lets start with configuration of interface ge-0/0/7 where 3 logical units have been defined and this link is made to participate in 3 vlans correspondingly.

MX104> show configuration interfaces ge-0/0/7
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 10.10.10.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}

However later some requirement change and because of it you need to change the ip addressing on one of the unit from 10.10.10.5 to say 20.20.20.5.

Now one way of doing this in Junos is to configure the new address in below fashion!!

MX104>edit
Entering configuration mode

[edit]
MX104# edit interfaces ge-0/0/7

[edit interfaces ge-0/0/7]
MX104# set unit 100 family inet address 20.20.20.5/30

But this has created an additional row under the interface stanza for which we have to write one delete statement to delete previous 10.10.10.5 address.

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 10.10.10.5/30;
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}
 
[edit interfaces ge-0/0/7]
MX104#delete unit 100 family inet address 10.10.10.5/30

Final config is:

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}

This method is fine for one change however not a very quick method. Junos gives us ability to change this value in very quick way by using “rename” command.

(NOTE: I did rollback the changes made above before proceeding further in order for interface configuration to be at same stage from where I started my blog)

Rename command renames the value of particular variable to new value and you need to mention the whole command hierarchy or go to level where you want the change to be applied. This is easy method to achieve same thing in less number of changes.

[edit interfaces ge-0/0/7]
MX104# rename unit 100 family inet address 10.10.10.5/30 to address 20.20.20.5/30

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}

Now, what if you want to change all IP Addresses under interface ge-0/0/7 stanza to use 20.20.20.x address rather than 10.10.10.x.. 2 methods can be set/delete and rename as we saw above however we have to define 2 rename statements in our case to change the ip addresses on remaining unit 200 and unit 300.

Again Junos is to the rescue and this time we will use another command “replace”. Replace command replaces the pattern you want to be replaced with new pattern.

Let’s see it in action.

Below is our configuration after we changed unit 100 with new ip address using rename command.

MX104> show configuration interfaces ge-0/0/7
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
} 

Now we have to change the ip addresses on unit 200 and unit 300 and in that case we can achieve this by using below command:

[edit interfaces ge-0/0/7]
MX104# replace pattern 10.10.10 with 20.20.20

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 20.20.20.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 20.20.20.13/30;
    }
}

Pretty exciting and fast !!! 🙂

One thing to remember is that you have to be in exact hierarchy where you want this pattern to be replaced. If you are at the Top level i.e under edit hierarchy only, then this will replace all instances of 10.10.10 with 20.20.20 whereever it is in whole config and not just ge-0/0/7.

Let’s see this in action one more time.

below is our configuration resulting from replace method. Now lets assume that we have to change all units and accordingly vlan’s last 2 digits from 00 to 10.. so unit and vlan id needs to be changed from 100, 200 and 300 to 110, 210, and 310 respectively.

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 20.20.20.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 20.20.20.13/30;
    }
}


[edit interfaces ge-0/0/7]
MX104# replace pattern 00 with 10

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 110 {
    vlan-id 110;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 210 {
    vlan-id 210;
    family inet {
        address 20.20.20.9/30;
    }
}
unit 310 {
    vlan-id 310;
    family inet {
        address 20.20.20.13/30;
    }
}

So that’s all, I hope you liked this article and will make use of these commands in your day to day operational work or troubleshooting. In future blogs we will see more useful commands and till then, have a nice day..

 

Regards

Mohit Mittal

 

 


	

Route-Reflection in JunOS

Let’s talk about one important concept in Route-reflection configuration in Junos.

To start with, there are 2 main IPv4 routing-tables in Junos which are inet.0 and inet3.0. inet.0 is main global routing table and inet3.0 is used in MPLS Layer 3 VPN and this table stores the egress address of an MPLS label-switched path (LSP), the LSP name, and the outgoing interface name. Only BGP accesses the inet.3 routing table. BGP uses both inet.0 and inet.3 to resolve next-hop addresses.

Now let’s configure the Route-reflection in Network. We will using 2 PEs and 1 RR

MPLS Network_1

Config on PE1:

PE1-re0> show configuration protocols bgp
local-address 10.198.123.204;
group L3VPN-RRs {
type internal;
family inet-vpn {
unicast;
}
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
export L3VPN-Export;
vpn-apply-export;
neighbor 10.198.123.235;   <<<<<<<<<<<<<<———- Router ID of RR
}

Config on PE2:

PE-2-re0> show configuration protocols bgp
local-address 10.198.123.205;
group L3VPN-RRs {
type internal;
family inet-vpn {
unicast;
}
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
export L3VPN-Export;
vpn-apply-export;
neighbor 10.198.123.235;
}

Config on RR (relevant configs only):

RR.re0> show configuration logical-systems l3vpn-RR
interfaces {
lo0 {
unit 3 {
family inet {
filter {
input Protect-RE;
}
address 10.198.123.235/32;
}
}
}
}
protocols {
bgp {
local-address 10.198.123.235;
mtu-discovery;
log-updown;
family inet-vpn {
unicast;
}
group l3vpn-client-group {
type internal;
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
cluster 10.198.123.235;
neighbor 10.198.123.204;
neighbor 10.198.123.205;
}
.
.
.
.
routing-options {
graceful-restart {
restart-duration 500;
}
router-id 10.198.123.235;
autonomous-system 65004;
}

BGP is established between PEs and RR

PE-2-re0> show bgp summary | match 10.198.123.235
10.198.123.235       65004      19154     12204       0       5 3d 23:20:04 Establ

PE-1-re0> show bgp summary | match 10.198.123.235
10.198.123.235       65004     19154     12326       0       1 3d 23:20:38 Establ

RR-re0> show bgp summary logical-system l3vpn-RR | match 10.198.123.204
10.198.123.204       65004     12336     19179       0     34 3d 23:25:10 Establ

RR-re0show bgp summary logical-system l3vpn-RR | match 10.198.123.205
10.198.123.205       65004     12212     19179       0     10 3d 23:24:31 Establ

PE-1 is advertising routes towards RR with next-hop address as its own loopback. All well n good.

PE-1-re0> show route advertising-protocol bgp 10.198.123.235
Data-VPN.inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                          Nexthop             MED     Lclpref   AS path
* 10.12.204.128/32     Self                       100       I
* 10.12.240.0/30         Self                         100       65012 I
* 10.12.240.128/32     Self                        100       65012 I
* 10.204.12.0/30         Self                         100       I

M10i-L3VPN.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                         Nexthop            MED     Lclpref   AS path
* 10.0.0.240/30           Self                         100       65020 I
* 100.100.100.0/30   Self                         100       I

However wait a minute, we are not seeing any routes under BGP table on RR

RR-re0> show route receive-protocol bgp 10.198.123.204 logical-system l3vpn-RR
inet.0: 96 destinations, 96 routes (96 active, 0 holddown, 0 hidden)
Restart Complete
bgp.l3vpn.0: 89 destinations, 178 routes (0 active, 0 holddown, 178 hidden)
Restart Complete

Why is this??.. Now this is fundamentally an issue with how the things were setup.

As I mentioned above inet.3 table stores the egress address of an MPLS label-switched path (LSP) which is used by BGP table to resolve next-hop addresses which in our case is loopback ip of PEs however as RR is not in forwarding path there are no MPLS LSPs configured on it and in-turn no inet.3 table entries which is a problem and that’s why you can see all entries in output above are hidden as bgp table is not able to resolve the next-hop IPs in inet3 table.

So there are number of ways to resolve this and will be discussing two of them here. Simplest one and most widely used method is to configure a static route for loopback IP subnet under inet.3 rib as below.

[edit logical-systems l3vpn-RR routing-options]
RR.re0# load merge terminal relative
[Type ^D at a new line to end input]
rib inet.3 {
static {
route 10.198.123.0/24 {
discard;
metric 65535;
}
}
}
load complete
[edit logical-systems l3vpn-RR routing-options]
RR.re0# commit
re0:
configuration check succeeds
re0:
commit complete

Once you configure this, inet.3 table is populated with static entry and now BGP can use this to resolve the next-hop IP Address for each route and all entries are visible now in routing table.

RR.re0> show route logical-system l3vpn-RR table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
10.198.123.0/24   *[Static/5] 00:00:08, metric 65535
Discard
[edit logical-systems l3vpn-RR routing-options]
RR.re0# run show route logical-system l3vpn-RR table bgp.l3vpn.0
bgp.l3vpn.0: 89 destinations, 178 routes (89 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
.
.
.
.
10.198.123.204:12:10.0.0.240/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: 65020 I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: 65020 I, validation-state: unverified
to Discard
10.198.123.204:12:100.100.100.0/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: I, validation-state: unverified
to Discard
10.198.123.204:116:10.0.0.24/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: I, validation-state: unverified
to Discard

Another option is to let inet3.0 use the rib already calculated by inet.0 table by using the below command.

[edit logical-systems l3vpn-RR routing-options]
RR.re0# show
graceful-restart {
restart-duration 500;
}
router-id 10.198.123.235;
autonomous-system 65004;
resolution {
rib inet3.0 {
resolution-ribs inet.0;
}
}

Both of these methods are valid and it depends upon which one you want to use in your network. For 2nd method you can configure prefix-list to list down only the specific network you want to exchange.

So that’s all for today. I hope I was to make it easy for you to understand. Let me know in case you have any comments or queries. J

R
Mohit