Monday, May 27, 2013

Configuring bgp session on Juniper MX router


I have been fortunate to be working on one of the heavy duty routers found in the networking jungle. Juniper is an established and trusted brand among many ISPs and big enterprises. The MX series routers are industry leaders and combine the functionalities of an M series router and EX series switch. But this post will not delve into the product description. This post is more about how to configure a basic bgp session and putting some default policies to ensure that you receive and transmit correct routes.

You can do very cool things with BGP, the exterior gateway protocol that is used by everyone today to announce their route to everyone on the Internet.

How BGP works in a nutshell


This is a just a very brief introduction to BGP. Anyone even remotely interested in knowing BGP should google for more relevant links. We will also be concerned about a few attributes which we can manipulate traffic according to our whims and fancies.

Basically BGP is a path vector protocol which informs a router about the direction and the complete path to a particular destination. When two neighbors form a relationship they establish what is called a bgp session. After forming a bgp session and negotiating on timers such as holddown timer values they start sending all the bgp routes that they know. Whenever there is an update they send triggered updates although it may take a while for all the routers in the routers to know the update. Moreover whenever there is an update they have to run algorithms to figure out the new best route. When all routers have the new route they are said to have been converged.  This state of stabilizing is called convergence.

From a practical viewpoint, each organisation tells their neighboring organisation ie an ISP aka peer what public routes they want to announce to the world. The ISP then advertises these routes to its upstream providers or a peer ISP (there is a heirarchy of ISPs). Soon all the ISPs in the world know each other's routes. It takes some diplomacy for two ISPs to peer with each other. Currently there are more than 400,000 routes.

Every organisation is assigned an AS Number(ASN) from their local internet registries or IANA. All routing devices in a particular AS belongs to a particular organisation, which need not be confined to a single geographical location. Suppose there is a company X which has its routers in USA,UK and India. Then all these routers will belong to a single AS. Two AS establish BGP session with each other.

That is all you need to know before setting a BGP session for your organisation.

Prerequisites for forming a bgp session:

1) Ensure that your router supports BGP.
2) It should have adequate memory. Run show task memory command to check available memory. All routes take a maximum of 100mbs of memory

Before showing the actual commands, remember the sub-goals we are trying to achieve

1) Establish a BGP session
2) Start receiving route
3) Start sending routes
4) Load balancing and applying firewall policies.

Establishing a BGP session


1) First make sure you have acquired an ASN for your organisation and partnered with an ISP who is willing to share the full routing table.
2) Note down the wan ips assigned and the next hop ip as well as their AS number.

Remember that the default routing policy of BGP is to accept all bgp routes and export all active routes. A general practice is to establish a bgp session and leave it without announcing any subnets for a day so as to ensure that the bgp session remains stable and does not hamper your production network.

The following configuration will set up a bgp session with 200.10.10.2/30, ASN 200 and will not send or receive any routes.

set policy-options policy-statement test reject any
set protocols bgp group test type external export test import test peer-as 200 neighbor 200.10.10.2;
set routing-options autonomous-system 300 ;//your-asn


The above commands are self-explanatory. I have basically created a policy to reject all routes and have applied it at the input and output interfaces.

To check whether the bgp session is up, run the command show bgp summary and show bgp neighbor in operational mode. You should see the neighbor's ip and active under the state column. Anything else means the BGP session is not yet established correctly. Ensure the wan ips are reachable from one another. Otherwise run show log messages | last 10. It should give the error message as to why bgp session failed.

To check if the session is flapping, note the flaps and Last Up/down column. If the number is rising it means BGP is not stable and you should contact your upstream provider. Last up/down column tells how much time back the flap happened.

Leave this link for about a day and start receiving routes when you are sure there won't be any bgp flaps.


bgp session
A successfull bgp session between two routers
bgp session
Both routers are neither receiving nor sending any route

In the subsequent parts I will discuss how to:

  • start receiving and advertising routes
  • Load balance incoming traffic
  • Load balance outgoing traffic
  • Applying appropriate filters and much more

After these tutorials you should be able to run and manage multihomed bgp sessions successfully.

Part 2: Configuring BGP session and implementing import and export policies

Important links


1) Wiki on Path vector protocol 
2) Wiki on Autonomous system
3) Wiki on bgp

Tuesday, March 19, 2013

Showdown with Directi

By now I have given four interviews involving tricky technical questions from "The difference between a void object and a null object" to "explain how internet works to a layman". I have given two interviews on the phone with contrasting results. The first proper interview that I gave was to Birlasoft for an internship during summer of 2011. I had applied for a software programming and got a call from one of their employees.

Initially the questions were pretty simple and I could answer them with no difficulty whatsoever. But as they became difficult, I couldn't answer them alone. I was sitting in front of my laptop and occasionally had to use Google. He was asking standard textbook questions, I could hear him flickering through pages. Explaining the difference between C and C++ was easy, but soon NULL objects started to ruin the interview. Finally he said, "I don't think you know C++". That was that.

I had never wanted a software programmer job. Even in my CV I had highlighted computer network as my strength. In the evening I received another call from an employee in Birlasoft. "So you are into computer network and you've attended a few hacking workshops?". I was completely unaware of another interview. So standing in front of a chicken tikkawaala, who was scrubbing and scratching out each and every single piece of chicken biryani from his kadhai I answered some of the most strange questions you might come across.

"What is hacking?How can someone hack?". You might say this is an abstract question. Well, hear the other ones out, "How can I tell if my organisation has been hacked?", "Can you build a software which will prevent hacking? Or better a simulator which will hack someone's PC and then show steps how to unhack?"

I give you a moment to figure it out.

In the madness around me, I had to explain him a lot of things with a lot of patience. It was certain that I was not going to be an internee in this company.

The third real interview happened with me when I sat for DirectI which had come for campus placements in our college. I had cleared the first two coding rounds and was waiting outside a room allocated for interviews. It was a hot, dry, typical Ahmedabadi afternoon and I was sweating. Inside my heart was pounding. I was called in and offered some water by the HR as if I was the outsider. My name was called again and it was time to give a technical interview.

The interview began with telling something about myself. I quickly played out the standard template that I had stored in my brain. Perfect. The next question was to describe the company and it's product. Fortunately I had done my research and stored another template which I played out with ease. The next question was to describe how the internet works and the role of DNS in it. I pounced upon the question but while describing I realised that it's impossible to explain everything. It is so vast that to describe each and every aspect of it would take hell lot of time. Thankfully the interviewer interjected and asked the next question, "What is a MAC and how does it help sending packets?" A few questions about Linux and operating systems were also thrown in but we both were interested in talking more about computer networks.

When I was asked, "Do you follow any blogs, or forums, like hackernews?" I was sure this was going to go just like Birlasoft. Fortunately that did not happen. Finally I was asked about workings of the humble traceroute. A simple yet versatile software, it iexploits many network fundamentals. A brilliant question to ask!

I felt ecstatic. I had cleared the first interview round. A final round remained. The final showdown remained! The last round was supposed to be a telephonic round. The problem that comes with it is that you cannot see the interviewer's face, his reaction to your answers. I had no way to judge whether he understood what I told him. The last round with a faceless person sounded very daunting. I was given a Blackberry and instructed to answer a call in the next few minutes. Waiting alone in a small cube it felt as if I was being put under interrogation,and that a dark, shady figure would soon be putting an end to my misery.

Author's imagination of the FacelessTelephone Interviewer
Suddenly the Blackberry came to life and started vibrating. I quickly pressed the green button and a voice came to life from the other end. I was asked to introduce myself. I quickly ran the template. A few questions about Linux and Operating Systems in general followed. "What is a virtual memory?", "What is Swapping in Linux?" I was fairly comfortable answering such questions. Things became interesting when questions related to network programming came up. Things became difficult when questions regarding public/private key infrastructure and salting in hashes were thrown at me.

I must say I fought valiantly and defended my knowledge to the best of ability. The interview had went for more than an hour. Infact when I came out of the room someone joked that I should have used my own phone since they had to wait for me to return their Blackberry.

Me after the interview was over
I think you know the rest of the story. I got an approval from the interviewers, signed a bond which said that DirectI will sue me if I didn't follow the terms and conditions and got a place to sit in Directiplex. Although, I still wait for my nameplate.