IP CLOS – EBGP – Multipath Multiple-as

Leave a comment


We have seen how iBGP was used to do the IP Clos with a RR Setup, how about eBGP.

Configurations / EVE Topology – https://github.com/r2079/JDC

Two simple rules

  • All spines have connections to all leaves – eBGP
  • No leaf or No spine devices have interconnected BGP.

Here is the topology.



The picture says 1000 words here – How the physical links are connected that’s how the bgp flows.


Lets see the BGP Status on R1 and R2


Since the hurdles of multipath has been explained. The use ADD-Path is not required here, instead since the update comes from Different AS numbers (R4 and R5) giving out the same update, we have to use another knob called MULTIPLEAS. This has to be on all Spine and leaf devices so that proper Load Balancing can be done along with EXPORTLB policy in the forwarding table.

Lets see one of the routers


Verification from R6






BGP ADD-PATH – Summary

Leave a comment


First things first, I have been getting a lot of requests to upload the lab’s which i illustrate as is, so i shall be uploading them to a Github page with initial and final-configs and Instead of vagrant i shall be using EVE-NG as a tool so that you guys can import them easily.


Going through Fabric-Path and CLOS concepts, got myself started with 3 Stage Clos and as a part of understanding it, discovered something.

Why –  To make sure Servers at one end have equal cost path to the servers-at other end, at scale the spine accordingly optimizing the CAPEX.

Simple words, in the below topology, we need to make sure that R6 has equal cost to R7 and vice-versa.


Protocols and setup

-> OSPF for the entire domain and Ibgp to peer between RR (R2) and all other loopbacks, we use OSPF so that Ibgp peering will be over Loopback and also for load-balancing protocol Next-hops

-> Default routes on R6 and R7, load-balance (per-packet) on all-routers (where technically required)

-> R3 AND R4,R5 has static back to loopbacks of R6 and R7 respectively, advertising them into OSPF will defeat the purpose obviously and these static routes are advertised into IBGP.


Lets quickly hop to R2 RR and see the bgp status, should be fine.

Ok, we have routes coming from R4 and R5, looks like there is a problem here, RR is only accepting the routes from R4 because of lower Router-id and R5 is not best, when this happens, from an End-host perspective, if R6 Sends packets to R2, it will only forward to R4 as it has only best path, can let that happen so lets do “MULTIPATH”


Added multipath, but looks like protocol has accepted it but Junos is yet to declare the other route as Active Next-hop, we need to write “EXPORT-LB” policy, lets quickly do so that it install the Next-hop into forwarding table.


Ok, things finally looking good, let see from R6 , if its getting Load-balanced.


Things look bad here, looks like R4 is still the same router which is getting burdened even though R5 is active on the network, let see why, lets get down to R3 and see how the route towards R7

Ok, we know the culprit, we have two next-hops but LB policy is missing, so lets quickly add the policy so that R3 can send packets to Two nodes equally.

Lets test the theory

Looks like we have accomplished what we have got, but wait I title this article as ADD-PATH, so how is that this is going to end ?

Well its not, Lets do one thing, Break the link between R4 and R1, it should not be a big problem right, R2 has still got the link,  R1 has got the link to R5 still a perfect candidate for LB.


Intrestingly, as Soon as R1-R4 link goes down, the path from R3 is removed , while technically R1-R5 is still available and healthy, Now comes the core topic of the post, Lets look at R1, am enabling the links.

As we can see above, RR R2 is only giving one route via R4 when it has two routes for forwarding( Remember we did multipath and export-lb on R2). Well, its not a bug, thats how BGP works, BGP would consider and advertise the best-path , in this case via R4 because of its lowest router-id.

In-order to fix this and let R1 know that there is another path available, you might think “why not multipath” , well multipath will only work when you have two paths, when you have only one-path here, there is no point of multipath.

Lets add BGP ADD-PATH send on RR as it has to send and ADD-PATH RECEIVE on R1 as it is the client. Adding ADD-PATH will reset the neighbor so do it with caution if you are on production.

Ah, finally we have R1 with two paths advertised, after this again all rules apply, first do multipath and then do LB for the new-hop.

After doing that if we go back and do the test on R6, Perfect.


Next Post will be on EBGP and IP-CLOS.



Rakesh M




ZTP With VQFX-1K – Proved to be Possible

Leave a comment


As I continue to study on Juniper DC realm, from the official blueprint it looks like ZTP is the first beast to tackle. I was skeptical if it would be possible to deal ZTP with VQFX and it looks like we can definitely do it. I have not tested anything related to upgrade, but one can imagine if we are deploying a Image (virtual-one) we are already aware about the Junos version and am not sure if it is really possible to upgrade one easily as a real-device, so I shall keep it to only configuration.

First Things first

-> What I have used Hardware – Everything done on a single server – Dell R810

-> Software – Vmware workstation (Ubuntu server with VSFTP/ISC-DHCP-SERVER installed)  and VQFX over Vagrant.

This is how the network is connected – By this time you should have understood how bad can one Possibly draw.

Prepping the Server

-> First, Understand DHCP is the heart of ZTP, you need to know on what options that it operates on, why a specific option is required and what it does, I shall write a detailed post about it but as of now we have to setup DHCP server, I have used isc-dhcp-server on ubuntu, simply because of the fact, Juniper has documentation for it.

The config file looks like the below.

r@ubuntu:~$ cat /etc/dhcp/dhcpd.conf
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;
default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;

# JUNIPER VQFX-1K ZTP Configuration

subnet netmask {
option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
option space NEW_OP;
option NEW_OP.config-file-name code 1 = text;
option NEW_OP.image-file-type code 2 = text;
option NEW_OP.transfer-mode code 3 = text;
option NEW_OP.alt-image-file-name code 4= text;
option NEW_OP-encapsulation code 43 = encapsulate NEW_OP;

host vqfx1k
hardware ethernet 02:05:86:71:3d:07;
option tftp-server-name "";
option host-name "vqfx-1k-via-ztp";
option NEW_OP.transfer-mode "ftp";
option NEW_OP.config-file-name "/srv/ftp/test.conf";

As per any Basics of DHCP, you need to have an interface which belongs to the subnet-pool you are going to distribute and then mention that Interface in the /etc/defaults/isc-dhcp-server


-> Hardware Address below is the interface address of Xe-0/0/1 , you can use wide varitey of parameters for ZTP and also not use anything at all, for this demonstration


The final service is the FTP service, this is required to copy your files and OS Images to the Router/Switch, when you install vsftpd, you need to enable it for anonymous login, rest all at their defaults, the DEFAULT directory which is uses will /SRV/FTP, so I have copied my configuration file to this directory.


Prepping the VQFX

-> Default it comes with “auto-image-upgrade” under chassis, for your testing it still comes with the same, make sure you put it in the same network as your DHCP server would connect to that all.

This is how the VQFX boots – up


Observing the status on DHCP – Server is Active

Am now configuring “set chassis auto-image-upgrade”, this option comes by default on a Hardware is what I read, but for VQFX, and for testing we have to enable as I see that Juniper didnt include this in the configuration, Documentation says we have to do “request system zeroize” and then with auto-image-upgrade as the default set under chassis, that will take-over.

observing DHCP-server, looks like it allocated the IP 107 as per the configuration.

And instantaneously, configuration is applied on the device and If you notice the Hostname is now changed.

Just to convince myself that we are already in that era, i renamed the vendor-id field in the ztp-config file to see if its all real, again it looks to be real. Welcome to ZTP.



VQFX10K on Vagrant and Merging with LAN Network for Ansible next-steps.

Leave a comment


On my prep work for  DC Exams and also to tryout Emulation , I have  tried all variations of VQFX (in ESXI 5.5/6.5, EVE-ng and now on a bare-metal server) and i think bare-metal server over Vagrant is the fastest out of all three.

The problem with Vagrant was simple, i was not able to integrate it over LAN, as i wanted to see some ZTP/DHCP server, Ansible communicating over it. So , after some exploration this is how it is possible.

Am covering all the installation steps, just in case if anyone of you are interested in this approach.


First things first, make sure you have installed Vagrant and also you have git installed on your system, nothing fancy if you have never used it before, its as simple as installing GNS3 or any other package. Even if you are new to linux, it is not difficult at all.

-> Clone the Git-Package – https://github.com/Juniper/vqfx10k-vagrant

[If you like to operate inside Vagrant it is just fine you don’t have to do this EDIT, my case my i have server in my Lan and i want to access QFX over telnet in my Laptop, so editing this file so that one / more interfaces are bridged to our LAN NETWORK]

Checking the status with [vagrant up]

[my interface GIG4 in my server, so selected the same]

[Checking the Status – now it should be running]

[The 192.168.192 is actually from my LAN network, and QFX interfaces are configured to obtain DHCP by default]

[As you can see i can reach the qfx now just fine, remember to enable telnet and local-user lab for comfort 😉 ]


Next possible thing is to see the ZTP / Related DHCP parameters if possible over VQFX (I doubt but I will give it a shot) and then see little things on how Ansible will help us in configuring VQFX.



VQFX Test and Opinion

Leave a comment


Similar to VMX , have tested VQFX image and I have to say, the whole setup process is a pain.  Full feature testing related to DCX is not done but here are some points


-> Any simulator which can run qcow2, I have apparently used UNETLAB

-> 8GB Ram (technically you can get away with even less) and 6 VCPU’s

-> vqfx10k-pfe-20160609-2.vmdk and vqfx10k-re-15.1X53-D60.vmdk – Two instances for the boot.


The procedure of uploading to EVE-NG is fairly easy and can be found in many websites so i wont be stressing on it, If anyone wants this to be blogged let me know, but it is straight forward.





RE settings that I have used are as follows, not changed much made CPU 4 , increased RAM to 4096 and edited ethernet ports to 6. PFE Settings are left as usual.



Note – From here, it would take nearly 40 minutes for you to just leave the system, it took a near to 40 minutes for me for FPC to become online. All through I was troubleshooting out of nothing from the instance start of 10 minutes which yielded nothing.

After all the wait, commit is not what you compare with VMX, a commit would take more than 30 seconds in some cases, while since we do not have a better option other than this, i guess we have to live with it. I tried the one in ESXI Instance, problem with that one is the scaling, its not easy as an emulator drag and drop and you have to go about editing virtual-switches to expand the topology.


All in all, its a pain till it is developed similar to VMX but should be able to help JNCIX-DC Preparation. I have run sample OSPF Between VQFX 10GIG and VMX 1Gig and didnt had any problems.


Ping is not at the greatest times as we are running in a emulator mode, I will be labbing a lot more on VQFX shortly and will also testing out the vagrant version of it to document more








Vmx 17.X Image Boot in Qemu and Observations

Leave a comment


I had to test some of the available features for Vmx 17.x image, 17.2 R1 Image and here are my observations when tested in Qemu Emulator based on Eve-Ng.

Two Node Topology.


Image and Memory Details –

-> One Router – Split into Two Qemu Instances – VCP/VFP (Control Plane / Forwarding Plane) so you need to have both of them.

-> VCP – I have allocated 2 Vcpus and 2048MB of RAM / VFP – 3 Vcpu and 6096MB of RAM

-> You can go with the lower Memory / Cpu allocations, I had the resources so allocated them just to be on a higher side.


Requirement – EM1 Should be connected for both VFP and VCP without that these will not function.


The boot process took more than 20 minutes to me, may be because I was using a USB drive to load the image and Disk IO must have been slower, else 11-15 minutes should do.  The auto-image upgrade will irriate you and hence I disabled it.


Lets look at routing engine and forwarding plane, PFE is booting into a Local Linux shell Mode. We wont access this box unless required for troubleshooting, all the Access is on VCP.


You can log into the forwarding plane for an instance but the speed of interaction with VFP is very slow, understandably it has to fetch it from another Qemu Image via EM1 interface.


Performance over Qemu Simulation is satisfactory and should be a good tool for JNCIE-Lab preperations, needless to say it will help all other types of study requirements as well. With an enhanced processor and with SSD disks, i guess the performance will improve dramatically.


I shall be shortly testing VQFX image as well and will update with similar Findings.



Quagga – Installation



Quagga Routing suite is fantastic and being used by Many .vendors to do the Basic Routing and to an extent even the powerful Routing on a Linux or custom built Node. We also know that cumulus linux uses Quagga as an underlying Software Suite for this.

-> Ubuntu Linux for Quagga

Lets see the Installation


Once Installation is done, verify if service ports are open in /etc/services File.

Make sure IPV4 Forwarding is enabled. Edit /etc/sysctl.conf as Below

Move the sample configuration file and rename then as per below, you can create your own conf files if you want , I just used the sample ones for this demonstration

Make sure appropriate Routing daemons are Switched ON

This is the important Part, Quagga by default can be run with user ‘quagga’, hence rename everything to ‘quagga’ , a user quagga is already installed during the installation

Do a restart to the process, if it does not fix, reboot the system and start the quagga process

Thats it, continuing this we will then setup an OSPF peering with Juniper VMX to move further


Rakesh M

Older Entries