Tag Archives: networking

Life and Times of an Unemployed Professional Speed Dater #3

The Conclusion

Over the past couple of months I have had a number of ups, downs, doubts, smiles, bad and good days etc, but all were needed for me to get to the point I am at now, in coming up with a conclusion to this piece, when I started up this blog, I never would have thought I would be writing about this topic. Shows how life can throw some grenades aye!

When I look back at all the dates I have had, there were a few major takeaways that I would like to pass on to others for consideration:

  • Keep all your options open, but know what you want
  • Ask for an opinion and be willing to help yourself
  • By keeping up a focussed routine it will keep you prepared for anything
Keeping your options open, but know what you want

Originally I said to myself, I only wanted to do contracting roles, as being at $lastjob for 6 months it would look bad on my CV, if I went to another company and the same situation to happen, so my mindset was to avoid this at all cost. However I came to see quickly that this single mindedness was going to get me nowhere. Keeping all the doors open allowed me to see what the whole job market was like and to be able to evaluate my skill set to get an accurate market value on myself. Additionally, with eyes wide open, I was able to confirm exactly what I wanted from my next position and company. This fact shouldn’t be undervalued and/or underrated, although I was looking for a job as soon as possible, I still had to think about the best situation I’ll be putting myself into.

Keep A Routine

People may not like the mundane feeling of getting up and going into an office however what it does do is gives you a routine. You know at X time you need to get up and out or do something. When you’re looking for a job you are basically moving to your own beat. For some, that may suit them, but I found that once you get out of a routine it gets harder to get back into one especially if you have been dancing to your own tune. Whether it means you getting out of the house or staying in, keeping some sort of life structure will help so much! As a side note, the routine I kept was renting desk space from WeWork in London Fields, Hackney. I personally didn’t want stay at home, so going into an office and just keeping that office environment was good to keep me focused.

Asking for help is Good

There is a difference between asking for views and opinions from people, you interact with on day to day based, I’m a chatty bugger on NetworkToCode, and constantly asking basic questions or ‘fishing’ from others. This actually took me some time to work out, as simple as it sounds. As I believed asking for views/opinions would make me come across as only using them for their professional connections, which was never the case. People are willing to help others that are willing to help themselves. Never forget this, always go that extra step yourself before asking, within reason, of course!

There were a few minor points, as such:

  • Have a wingman for different situations
  • Dating on your own is also cool
  • Playing the field is acceptable

Would be useful, but these minor points can fit within aspects of the major takeaways!

Throughout this whole piece I have attempted to portray speed dating as an analogy about how I went through the process from going from being a self made unemployed specialist to, come 10th August 2018, a brand new excited member of a Network Team, but more importantly an organisation that honestly made me feel wanted and a company that I, wholeheartedly, believe will improve on my current skill set, help develop new skills and hopefully I can drop a few nuggets of knowledge to help the team move forward in the best way possible. As I said earlier, I have been fortunate enough to have a strong squad of friends and family behind me at a personal level, who have allowed me to progress during this time, but I can’t forget the people who, in a professional level, have pointed me in the right direction. As I’ve mentioned both @Ruiari and @irldexter have helped me out plenty and the day I do get to put faces to names, I will be owing them a beer or two! Additionally the guys and girls at Hamilton Barnes, they had been a great help although I didn’t get my position from them, the advice and nuggets from them were extremely valuable!

This article had taken longer and much more open than I had expected, and to be honest, I am pretty glad this is the case. The notion that you need to have a new job lined up, before leaving your current position, is always ideal however we don’t live in an ideal world. These couple of months have shown me that: Struggling, Doubting, Re-Evaluating, Adapting, Progressing, Failure and Success, these are all situations that can be apply whether you are employed or not, but being happy within yourself and the decisions you make is more important than sticking it out in a place you feel isn’t the best fit or a place where you have mentally and emotionally given up. Once you have gotten to that place, you will see that you can find more opportunities by backing yourself and taking that left turn to happiness compared to staying on the straight and narrow.

Share this:

Life and Times of an Unemployed Professional Speed Dater #2

The Theory

With all the background and life story about how I got myself into Unemployment out of the way, it’s time to explain the probably still confusing part, the Professional Speed Dater.

The term is something that I came up with to best suit my situation. The whole process of applying for a job, once you have completed an application, is exactly what speed dating is being sold as! This is a bit cheeky as I have never actually been speed dating before haha, but if you look at the stereotypical scenario of speed dating I would have thought you would find this:

  • See an event you like
  • Make an application online
  • Someone makes sure you are suitable for the event
  • Event invite is confirmed
  • Turn up hoping for the best and being yourself
  • Chat with multiple strangers about the same thing within a set time
  • Someone asks you how it went after the event
  • Nervously wait and hope for positive news
  • Eventually success or failure is the outcome

When looking at that process and comparing it to the job interview process, if it’s not the same it’s damn well very close! Just like with actual speed dating you get the option of going it alone, aka searching for companies and applying directly with them, or to go with a trusty wingman to make the event a bit easier knowing you have someone who has your back. If you hadn’t already guessed, in the Professional Speed Dating arena your wingman is your recruiter! The role of the recruiter is to find you suitable positions, put you in the best situation to succeed, and then chase for details after you have finished. If this isn’t the definition of a quality wingman then “boi”, I don’t know anything about anything!!

Luckily enough, once I started getting my profile out on job sites and giving some recruiters and old contacts a call, I was getting quite a lot of noise about potential roles and companies. However, I quickly came to see that just because you get a lot of noise coming towards you, this doesn’t automatically mean you will enjoy what is being heard.

Everyone will have their own views and opinions on what recruiters can actually do for engineers, whether they are a help or a hindrance. In my experience over the last couple of months, I found that 70-80% of the recruiters that contacted me via finding my CV from $jobsite didn’t help as much as I thought they would. A lot of the time, I would get a call about $job, ask for more details and/or a job spec in an email, then get no response back or they would be talking about positions that were completely outside of my skill set… In my mind, that was illogical, as recruiters will get a fee if they fill a position. For them not to come back to me or for them to at least say they found someone else more suitable, would have been useful. It started to become by the bye, if those type of recruiters weren’t coming back to me.

The recruiters that I found to be the most helpful were the ones I made the first contact with. Whether that was by email or by giving them a call, it seemed that they were more focussed and willing to put my name ahead of others. Whether this was the case, again I’ll never know, but it was much more reassuring to feel that they actually gave a damn and communication between us was much more open and honest around the expectations I had of them, what they were able to do for me, and what I was looking for at my next position. With hindsight I would have actively engaged more with recruiters, I connected with on Linkedin (which had been an amazing resource) for this exact reason!

Date Night!

Having all the pieces in the place and a better understanding of what i’m actually talking about, he most interesting aspect of being the Professional Speed Dater…. Dating Night! Over the past couple months, I’ve had an interesting mix of Dating Nights, to be fair, I think I’ve put in a good show for the most part, as I managed to pass the Speed Dating Event and get multiple date nights with potential suitors. Of course, not all went smoothly, I did have one noticeable date that I wouldn’t say was bad, I can only describe it as offensive haha!!! I won’t go into the specifics about any of the interviews per se but what I found, generally all dates follow the same type of structure, which coming from my perspective, can be helpful – but also created an interesting issue. Going through the multiple dates in a very short space of time, following the same flow, you will naturally pick up on cues from the interviewer(s) on what type of question(s) are coming next.

I can’t speak for other industries but in the I.T. world, commonly you will have two types of dates: Soft Skills and Technical (Hard Skills). As silly as this sounds, in my opinion, Soft Skills are more important to get right for a technical role compared to the Technical interviews themselves.

Given you’ve made it this far, I can throw out a wild statement but before you stop reading, let me explain.

Any techie will know, when you go into a technical interview, you know the range of technical knowledge will be tested on. You expect to get logical/illogical scenarios asked of you that you either know or don’t. This actually makes these type of interviews much easier to cope with as it’s very black and white. There are no grey areas, you either know how BGP, Spanning Tree or $Other_Random_Network_Topic works or you don’t. You are probably saying; “Well I know its a technical interview, so I can just revise over topics…. “, but given that every network is different and it truly depend on what $company is doing within their environment, trying to revise what potentially could be asked would be pointless. So for me, when it came to technical interviews, I would look at specific details that I knew I would forget, such as lower level packet details, port numbering etc but outside of that, as I said, I either know it or I don’t. There is no point in apologizing over things you don’t know or haven’t worked with before. Given this logic, if you don’t know everything asked of you, you can start to see why Soft Skills are just as important. Granted, I have never sat on the opposite side of the table interviewing before, so what I’m going to say could be 100% bollocks, but I believe that showing technical range will get you only so far, yet if you can show that you are a well rounded individual with the ability to learn, showcase your technical skills and be humble enough to ask for help, these character traits will get you remembered and potentially be that hidden 1% over someone who has that bit extra in technical knowledge.

That interesting issue I mentioned earlier, I had stated being able to predict questions and situations was a great card to have, however it can backfire epically when you get a simple question that breaks the dating norm. That question, that makes you overthink the whole date with you saying to yourself, How did I cock up such a simple question?!? What a simple but unexpected question can do to a polished interviewee can actually be amazing, as Theresa May shows when she was asked how she copes with having such a stressful job. One of these were thrown recently during a technical date night. It was a Soft Skills grenade while I was trying to predict what the next techie question was going to be. I honestly fumbled my way through it but was lucky it was towards the end of the night, so I managed to turn it into a funny story!

When I look back at all the dates and consider the whole picture, I am a little surprised that I didn’t get more of those unexpected/left field questions, as they probably would give the interviewer more of an idea, how $candidate deals with unexpected situations. Donal O’ Duibhir aka @irldexter has been a big advocate about how to structure the current ‘date night’ within technical fields, and how it’s getting outdated due to a move towards automation and working at scale. He has created a tool called Pansift to do automated expert screening. Pansift can help companies ensure what $engineer has said they can do, they can actually do. For me, this is could a differences maker that could:

  1. Help $company create a company relevant, repeatable set of the requirements that they can hand over during a technical date night, to get a full understanding of what level $candidates are at
  2. Help $candidate understand the importance of being prepared and fully understand their own limitations, and as said above, be humble enough to say I don’t know this. Additionally they will know the level of technical skills the $company is looking for.

The last sentence in point 2, this point is important and can be undervalued by the $candidate. Being humble enough to say I don’t know is one thing, however understanding that a position, at potential good company may not be the best fit for you personally, is such a valuable trait to be able to pick up on during any interview process, hell in life in general! A tools such as Pansift, if done right, could be deal-breaker for both $company and $candidate, as it will give both parties the oppunitunity to get an understanding of how each other works and if they want to keep moving forward together or go their separate ways.

Another undervalued notion, I wish I considered, was finding out how many dates were expected before getting a final decision. You may be thinking, what is he going on about now, but there was quite a difference between UK and US ‘dating’. Throughout my career, as of writing this, I have always had UK dates, which generally followed this set of dates (we will exclude conversations with our wingman):

  • First Date: Phone call
  • Second Date: Face-to-face dinner date
    • Dinner: Mum & Dad
  • Third Date: Marriage

For US date nights however they followed these type of dates:

  • First Date: Phone/Video Call
  • Second Date: Face-to-face day out
    • Breakfast: Uncle
    • Brunch: Aunty
    • Lunch: Brother
    • Dinner: Sister
  • Third Date: Phone/Video Call
    • Skype: Mum
    • Google Hangout: Dad
  • Fourth Date: Marriage

Side Note: I got a priceless nugget of advice from @Ruirai on the NetworkToCode Slack Channel, who did a presentation on the common interview process for the Big US based Tech companies. These slides were such a godsend, and I would suggest anyone who hasn’t gone  through this process before to give it a read. I found it helped with setting my expectations.

The biggest differences between UK and US dates were number of them and the amount of people you have to interact with. This was a bit of a mind blown moment, as at times, I had thoughts of I must have been doing something wrong, if they keep asking me to talk with a different person about the same topics but in a slightly different way. But then when I considered this from an employer’s point of view, it is important to get as much information about $candidate as they can and if you end up with multiple people coming to the same conclusion, generally you will come to the right decision. Not to say, that the way things are commonly done in the UK are bad. The UK process can be more condensed and quicker for both parties involved when compared to the US, which has its advantages. As the saying goes There’s more than one way to skin a cat – comes to mind 🙂

For my final thoughts, head over to Part 3!

Share this:

Life and Times of an Unemployed Professional Speed Dater #1


This is a bit of a left field post to appear on a so called Networking blog, but if you lend me your eyes for a few minutes all will be explained 🙂

The Background

So I haven’t actually posted anything in some time even though, I have had subject matters that I’ve found interesting. I’ve been looking at a few different things which have ranged from scripting/automation topics such Python and Ansible, to even attending an amazing Network focused automation course run by NetworkToCode (shout out to Jason Edelman and everyone at NetworkToCode). I’ve also been concentrating  on Next-Gen networking topics such EVPN, VXLAN, and have been looking into working towards my JNCIP-SP & JNCDS certifications (and other bits and bobs too).

The reason I haven’t posted anything is because over the last 18-24 months there has been a number of things (we could say challenging situations) that I’ve had to cope with with in my professional career. Looking back I probably let these circumstances impact my personal life too much and although these have been extremely frustrating and annoying, they didn’t kill me so it’s all down to learning (and I now know what I’m willing to put up with but more importantly I know what my professional worth is). These circumstances caused me to leave a position I had held at the British Broadcasting Corporation  (for nearly 4 years)  to pursue oppunitunity that I hoped would be a chance to move forward and progress to the next stage in my professional career. Unfortunately, after giving the position a good chance, and confirming to myself what I honestly believed, I decided the role wasn’t a good fit and I left with nothing lined up. So, on 1st June 2018, for the first time in 12 years I found myself unemployed.

Taking the step into the unknown wasn’t an easy choice and tbh I wouldn’t recommend it to just anyone as it’s a decision that should not be taken lightly. At the same time, you should consider a number of different factors that are important to you and your overall life situation. Before taking such a step or when I was thinking about leaving my position, I started second guessing myself and considering how my decision could affect others; whether that was family, friends, or especially my colleagues. The idea of considering my colleagues in such a decision, looking back, was an interesting one. I believed I was:

  • Dropping them in the shit by increasing their workload
  • Worrying about if I had explained what I was doing fully
  • Potentially leaving work half finished
  • Realising that I was a single point of knowledge in edge cases or projects

These were strong reasons at the time but with hindsight, although I believed these to be valid reasons, in my opinion they should not have been as big a consideration in the overall picture. Making my colleagues life easier would make me a good colleague/person however looking out for others when you are not happy in a work setting is simply taking your focus away from what is best for you and in this situation it was detrimental to me. I was spending more time in a negative situation, trying to do what best for others. This may all sound quite selfish and negative however sometimes being selfish and self focussed is the only way to make the best decision.

Once the decision was made and the process started, it was a relief being out of the negative cycle I had been in. I backed myself to find a better situation and was able to take a step back to re-evaluate what I was doing and where I wanted to go. With that being said, I quickly had the realisation of ‘oh shit, I’ve got no income or job’ barrelling down like a train with no brakes, which brought along its own stress and complications. Fortunately I’ve got an amazing circle of family and friends who are so supportive and understood what I was looking to achieve. Although, the fact remained that I had made myself unemployed and needed to find a job before I started eating into my house-savings, and for those of you who live in London you will know just how important these savings are given how shamelessly overpriced the properties in the UK’s capital are!

If I’ve peaked your interest.. Roll onto Part 2 🙂

Share this:

Border Gateway Protocol (BGP)

BGP Basics

What is BGP

Border Gateway Protocol (BGP) is regards as the most influential network protocols as it is backbone of the internet today. BGP is a Path Vector Routing Protocol, that unlike other routing protocols uses TCP (port 179, as its transport layer) to establish connectivity before exchanging routing information with another BGP speaker (peer). BGP communication can be done between same and/or different networks, these networks are known as Autonomous Systems (AS) with an  AS being a set of Routers that are managed by single entity, business and/or company. BGP uses routing information to maintain a BGP Routing Information Base (RIB) of Network Layer Reachability Information (NLRI) which it will exchange with other BGP peer or Peer ASs. BGP is a classless protocol, it can support any IP prefix regardless of class, this is both for IPv4 and IPv6. It is important to note that requires TCP connection first before building BGP connection, without that first established session a BGP peering never happen, however once that session is connected it will not have to made again unless a change is made. BGP uses Keepalive messages to ensure reliability of the session as it does not use any transport protocol-based keep-alive mechanism to determine if peers are reachable.

BGP Usage

BGP is largely (but not exclusively) used in large enterprises and data centre hosting environments where the need for single or multihomed to multiple Internet Service Providers (ISPs) connections are needed, this is known as Exterior BGP (eBGP). BGP is extensively used with Service Provider environments. BGP allows a large range of the policy based controls for an AS to influence and/or manipulate routed inbound and outbound traffic to help optimise the movement of traffic for their own needs. Additionally BGP can be used between BGP routers within the same AS to advertise internal routes with the same level of control as eBGP, with some small however important difference, this is known as Interior BGP (iBGP).

eBGP vs iBGP

There are some Key Differences between eBGP and iBGP that are important to note:


  • eBGP session is between BGP peers with different AS numbers
  • Inter-AS communication is by via eBGP
  • eBGP respects the AS_Path Path Attribute
  • Routes learnt via eBGP will be advertised to other eBGP and iBGP peers


  • iBGP session is between BGP peers with the same AS number
  • Intra-AS communication can be by via iBGP
  • iBGP commonly uses an IGP for network reachability and to establish BGP TCP session via Loopback address
  • Routes learnt via iBGP will not be advertised to other iBGP peers however will advertise routes to an eBGP peer

The above isn’t the full differences but just some of the main difference that need to remember. Additionally there are situations where some of these rules may need to be manipulated and can be done in design and/or configuration however that is for later

BGP Peering States

When establishing a BGP session there are 6 states that need to be completed before peering session comes up. The first 3 states are to ensure the TCP transport layer connectivity is there, once this has been completed then BGP connectivity is established with the final 3 states:

BGP State Connect Description
Idle TCP This is when all BGP connections will be refused. An Idle state occurs when the BGP session hasn’t been configured on the other BGP peer or BGP has isn’t enabled at all. Commonly, a start event is required from the other peer to prepare the TCP connectivity.
Connect TCP The router listening for TCP connections and is waiting for the TCP 3-way handshake to be completed:

  • If this is completed, then an Open message is sent and is transitioned into the OpenSent State.
  • If TCP connections fails, the BGP peer restarts the ConnectRetryTimer and waits for the remote peer to initiate a TCP connection and transitions into an Active State.
Active TCP This is when the BGP peer is trying to establish TCP connection.
OpenSent BGP When in the OpenSent, an open message has been sent by the BGP peer however has not received by the local peer:

  • Once the message has been received, checked and has no errors, the local peer will send a Keepalive message.
  • If a message is received, checked and an error is found then state is transitioned back to an Idle state.
OpenConfirm BGP When in the OpenConfirm, the BGP is waiting on a Keepalive or Notification message:

  • Once the peer receives a Keepalive message, it will move into the Established state
  • If the local peer does not receive a Keepalive within the negotiated session hold timer, it will send a Notification message and transition back to Idle state. The same will occur if the local peer sends out a Notification message.
Established BGP Having received the Keepalive message, the BGP session is fully Established. The peers are now able to exchange Update, Notification and Keepalive messages

BGP Message Types

As shown above, there are a number of different messages sent between BGP peers to Establish a session and when even the peering has been established, messages are used to ensure that both peers have synchronized routing information. BGP can only process a message after the entire message has been received, the maximum message size is 4096 bytes with 19 bytes being the smallest message size, this would be just be a header with no data. Each message type uses a fixed header size of 19 bytes with BGP Keepalives not include any data after the header, so they will always use the minimum size.

Each Message would be include the following:

Message Type Description
Open Once TCP connection has been completed both peers will send out an Open Message. This message starts the peering session, it provides details about the remote peer, in addition to details about supported and optional options.

These details are included:

  1. BGP version (normally version 4)
  2. AS number
  3. Hold Time
  4. Router ID
  5. Par-Len
    • If this set, it informs the peer that optional parameters should be expected
  6. Optional Parameters
    • This is where negotiable parameters are indicated, these would be authentication and capability extension such as Multiprotocol Extensions and route refresh.
Update An Update Message sends a list of new, withdrawn or types of routes from the remote peer. Depending on the routing policy of remote peer these may or not be entered into the Routing Table.

These details are included:

  1. Unfeasible Route Length
    • If this is set, it will tell the peer, the length of withdraw routes
  2. Withdrawn Routes
    • Lists IP prefixes that have been removed as they are no longer deemed as reachable
  3. Path Attribute Length
    • This indicates the total length of Path Attributes field. Its value allows the length of the Network Layer Reachability field to be determined. A value of 0 determines that neither Path Attribute and NLRI is present in the update.
  4. Path Attribute
    • The following properties for a route is included:
      1. Origin
      2. AS Path
      3. Next-Hop
      4. Multi-Exit Discriminator (MED)
      5. Local Preference
  5. Network Length Reachability Information (NLRI)
    • Lists IP prefixes that will be advertised as reachable via the AS
Keepalive It is important to always remember that Keepalive Messages are not used to ensure the TCP connection between peers is kept. They are used to ensure that BGP Hold Timers do not expire keeping alive the route exchange.
Notification Notification Message is used to inform a peer that there is an error with the BGP session.

There are 6 Error code numbers:

  1. Message Header Error
  2. Open Message Error
  3. Update Message Error
  4. Hold Timer Expired
  5. Finite State Machine Error
  6. Cease

In addition to 17 Sub Error codes (6 Open Message Errors and 11 Update Message Errors). These can found in RFC4271

Refresh Normally BGP can not readvertise routes that have already been acknowledged by a peer, if the BGP peer has been configured to soft clear of BGP sessions then peers will be able to exchange Refresh Messages. Some vendors you have to explicitly configure this, in Cisco you need to configure soft-reconfiguration whereas with Juniper it is set by default within JunOS.

BGP Attributes

Unlike other Routing Protocols, BGP primary function is to find the best path to a destination and not the shortest path. BGP uses a number of attributes to calculate the best path for any given destination prefix. These attributes can be broken down into 4 types:

Well Known Attribute Types
Well known Mandatory These attributes must be known and understood by all BGP speakers. Additionally must exist within the BGP update messages.

Attributes classed as Well Known Attributes:

  • Origin
  • AS Path
  • Next-Hop
Well known Optional These attributes must be known and understood by all BGP speakers. However they don’t have to exist within a BGP update message.

Attributes classed as Well Known Optional Attributes:

  • Local Preference
  • Atomic Aggregator
Optional BGP Attribute Types
Optional Transitive Attributes don’t need to be understood by a BGP speaker however the set flag(s) will need to be passed onto other neighbours.

Attributes classed as Optional Transitive:

  • Aggregator
  • Community
  • Extended Community
Optional Non-Transitive These attributes don’t need to be understood by a BGP speaker and the set flag(s) will not be passed onto other neighbours.

  • Multi Exit Discriminator
  • Originator ID
  • Cluster List
  • Multiprotocol Reachable NLRI
  • Multiprotocol Unreachable NLRI

A BGP Update message could include some, if not all, of the following attributes:

Message Information
 Origin (Attribute Code 1) The Origin Attribute confirms the source of the route aka where the route was learnt from. The Origin of a route can either be:

  1. I: Internal (0) The Route is learnt from IGP

  2. E: External (1) The Route is learnt from EGP

  3. ?: Incomplete (2) The Route is learnt by something that isn’t by Internal or External methods

The rule used for Origin is that: Internal is better than External which is better than Incomplete

 AS Path (Attribute Code 2) AS Path is a list of AS numbers that are between the source AS router to the our own AS. The AS Path is primary usages are to prevent Routing Loops, assist in the Path Selection and Policy Based Routing (PBR). BGP router will drop any routes received where it can see its own AS number within the AS Path this is how Routing Loops are prevented. The path enables the router to make policy decisions based on the presence of certain AS’s within the path. Additionally routes with a shorter AS Path are preferred over routes with longer AS Path
Next-Hop (Attribute Code 3) This Attribute contains the IP address of the BGP peer that advertises the route. The Next-Hop is used for reachability and reliable of for the BGP session. For eBGP it is usually the peering address associated with the physical link with another AS. iBGP works differently as you can have situations where due to rules with iBGP the next-hop address isn’t reachable due to learning the route from another iBGP peer, in this situation the Next-Hop can be changed by policy.
Multi Exit Discriminator (Attribute Code 4) Multi Exit Discriminator (MED) is used when there are more than one route to the same upstream AS. The route with the lowest MED value is always preferred by default.
Local Preference (Attribute Code 5) Local Preference is an important attribute as it is the first attribute evaluated in the Path Selection Process. Local Preference is used for Infra-AS traffic communications for BGP session. As the name, suggests is only used to influence traffic within an AS. Oddly BGP prefers routes with the Highest Local Preference.
Atomic Aggregator (Attribute Code 6) Atomic Aggregator attribute is a notification that tells other BGP speakers within the AS-Path that some information has been lost and/or changed due to route aggregation. This may affect the best path selection because a less specific route was selected over more specific route.  
Aggregator (Attribute Code 7) Aggregator attribute is set when an advertised route has been aggregated. This attribute contains the AS number and Router-ID of the Router that has performed the aggregation
Communities (Attribute Code 8) Community attribute is tag that is use to modify, filter and/or influence a common group of IP Prefix(es) to act in a user defined way. Communities uses 4-octets of space to represent its value. Communities are used in conjunction with PBR. A community is 32-bit value, that is common defined as AS/IP-address:User-defined ie 100:1 or 100 would be the AS or being the device loopback address with 1 being a value significant within AS100.
Originator ID (Attribute Code 9) Originator attribute is a loop prevention mechanism used within iBGP network using a Route Reflector. The Route Reflector attaches if own Router-ID to routes, so if it receives a route with its own Router-ID it will ignore the route.
Cluster List (Attribute Code 10) Cluster List similar to the Originator ID attribute is a loop prevention mechanism however if an iBGP network is used clustered set of Route Reflectors then routes have the Route Reflectors Cluster ID attached to the advertised routes.
Multi-Protocol Reachable NLRI (Attribute Code 14) Multi-Protocol Reachable NLRI has two main functions as defined in RFC 4760:

  1. Negotiates what non IPv4 unicast families will be announced between two BGP peers.

  2. Defines the Network Layer Address of the router that should be the next-hop of the destination families. Ie if you have advertised l2vpn bgp family the next-hop for this bgp family will be defined within this attribute.

When this attribute is used in a BGP Update message, the Origin and AS Path attributes have to be included. Local Preference attribute is additionally added to Update messages for iBGP peering sessions.

Multi-Protocol Unreachable NLRI (Attribute Code 15) Multi-Protocol Unreachable NLRI attribute is used to withdraw any BGP families that are no longer being advertised between BGP peers.
Extended Communities (Attribute Code 16) Extended Communities are the same as Community attribute however it has 8 octets of space to represent the community compared to 4 octets with normal communities. This allows 64-bit value, it can be represented as Type:Global-Administrator:Local-Administrator. It is important to note that you have set amount of bits you can use. You will have 16 bits for the Type, 16 bits, for the Global-Administrator (commonly the ASN/IP address) and 32 bits, for the Local-Administrator (commonly user defined).   

BGP Path Selection

When a destination prefix reached by multiple routes via BGP by default only one path will be advertised into the Routing Table. With this in mind BGP has used its Route Selection Algorithm to determine what path will be installed into the Routing Table. The algorithm uses the following steps:

  • Prefer the highest Local Preference Value
  • Checks what path has shortest AS Path
  • The Route with the Lowest Origin Value
  • If the route has a Lower MED
  • If the Prefix is learnt via eBGP is preferred over being learnt via iBGP
  • The path with the better exit out of the local AS. This means that the underlying IGP metric cost is taken into consideration, the path with the lowest IGP is preferred
  • The eBGP route that has the longest uptime or prefer the routes from the peer with lowest Router ID
  • Prefer routes with the shortest Cluster List Length. This is when you use a Route Reflector within your iBGP peering session
  • Prefer routes from a peer with the lowest IP Address

Some vendors have their own vendor specific additions to the path selection algorithm. Cisco use Weight before checking Local Preference and Juniper verify that the Next-Hop is reachable before checking Local Preference. With JunOS, if the Next-Hop isn’t verified then the route is set as a Hidden route and will need investigating.

Share this:

What is BGP FlowSpec?

I recently messed about with some Junos Automate Scripts that one of my colleagues had previously been working on, that could be used to add static routes to enable Remote Triggered Blackhole (RTBH) Filtering (which can be found here), and I found it was a bit rough around the edges (for people who aren’t cli junkies). As I do, I started looking into RTBH and saw that it’s a heavy-handed solution in trying to combat DDoS attacks against a network. RTBH technology has been around for a number of years now and has been defined in RFC 3882 and RFC 5635. In its most basic of terms, you can either blackhole all traffic from a source address and/or to a destination address by injecting the attacking/attacked prefix into BGP with a community that will rewrite the next-hop to a pre-configured discard route on edge routers. If you have massive DDoS trying to block every source address, it would be like going fishing with a shotgun. By blocking the destination address the attacker will have got their desired outcome. With that in mind, using RTBH is ideally a last resort solution. There is an alternative more subtle way of blocking unwanted attack traffic from our network. This alternative method is known as BGP FlowSpec.

What is BGP FlowSpec

BGP FlowSpec is defined in RFC 5575. RFC 5575 defines a new Multi-Protocol BGP Extension MP-BGP, in addition, with new Network Layer Reachability Information NLRI. The new NLRI collects 12 types of Layer 3 and Layer 4 details that are used to define a Flow Specification then actions are assigned to these routes dependant on the user’s needs. If you wanted to look at FlowSpec in a simple form, it is a firewall filter that is injected into BGP to filter out specific port(s) and protocol(s) just as a normal ACL would do. BGP uses NLRI to exchange routing details between BGP speakers, each of the MP-BGP Extensions have their own NLRI details that are identified by their Address Family Indicator AFI and Subsequent Address Family Indicator AFI. Usually IPv4 unicast routes (also known as BGP families) are the default for BGP peers, if non IPv4 unicast routes need to be exchanged ie IPv6, EVPN, L2VPN, FlowSpec routes, then MP-BGP defines the relevant NLRI of the router that should have the next-hop of the destination families. This had been defined in RFC 2858 and RFC 4760. As stated above, as of writing, there has been 12 NLRI types defined for BGP FlowSpec, these fields will be added to NLRI field within the BGP Update Message and advertised to peers. In addition, FlowSpec does not support IPv6 yet.

FlowSpec NLRI Types

These are the 12 FlowSpec NLRI types:

Type NLRI Component
1 Destination Prefix
Defines the destination prefix to match
2 Source Prefix
Defines the source prefix
3 IP Protocol
Contains a set of {operator, value} pairs that are used to match the IP protocol value byte in IP packets.
4 Port
This is defines whether TCP, UDP or both will be packets will be influenced
5 Destination Port
Defines the destination port that will be influenced by FlowSpec
6 Source Port
Defines the source port that will be influenced by FlowSpec
7 ICMP Type
8 ICMP Code
9 TCP flags
10 Packet Length
Match on the total IP packet length (excluding Layer 2 but including IP header)
Match on the Class Of Service flag
12 Fragment Encoding

NOTE: Not all 12 types have to be defined for FlowSpec to be enabled

FlowSpec Actions

RFC 5575 has defined 4 minimum Actions that routes matching FlowSpec NRLI types can take. These actions are carried as BGP extended communities added to the FlowSpec route. These actions are:

Traffic-Rate Community

The Traffic-Rate community is non-transitive, that tells the receiving BGP peer, what to rate limit matching traffic to. If the traffic needs to be discarded or dropped, this will be limit of 0 should be used.

Traffic-Action Community

The Traffic-Action community is used to sample defined traffic. This allows sampling and logging metrics to be collected from the FlowSpec route, that could be used to get a better understand of the attack traffic.

Redirect Community

The Redirect community allows the FlowSpec traffic to be redirected into a Virtual Routing and Forward Instance VRF. As the same Route-Targets and Route-Distinguisher can be used, you are able to import routes into a dedicated blackhole VPN or any other VPNv4.

Traffic-Marking Community

The Traffic-Marking community is used to modify the Differentiated Service Code Point DSCP bits of a transiting IP packet to the defined value. This could be used to set to FlowSpec routes to highest discard probability, allowing traffic not to dropped/discarded until co

FlowSpec Rule Ordering

It is important to note, that unlike normal firewall filters, FlowSpec routes use a different method of ordering rules. Most firewall filters and/or ACLs use the top-down approach, where in, once the filter has a match any other rules afterward are not inspected. With FlowSpec a deterministic algorithm to order the rules is used. By comparing the left component of each FlowSpec NLRI, the algorithm will use the following details to order FlowSpec Routes:

    1. If the types differ, the lowest type is used. If the types are the same then component values within that component are compared
    2. For IP values, the lowest IP prefix is chosen. If the IP addresses are the same then most specific prefix is used
    3. For all other types, the binary string of the contents is compared to determine the order

Validation Checks

Validate checks within FlowSpec are important, because you could get into a situation where, if no validation checks are done, FlowSpec route(s) could be injected by an attacker that doesn’t own a set of prefix(es) that could blackhole traffic. Like any other unicast BGP route, the next-hop address must resolve for the route to be usable, as per the normal BGP path selection process. In addition, to a valid next-hop, RFC 5775 has defined the follow must be valid of a Flow Specification:

    1. The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification.
    2. There are no more specific unicast routes, when compared with the flow destination prefix, that have been received from a different neighbouring AS than the best-match unicast route, which has been determined in step 1

The overall goal is to confirm that the originator of the FlowSpec route is the same as the originator of the BGP unicast route, this is done by either using BGP’s AS Path attribute or if that isn’t present (in iBGP situation) then the Peering IP address is used.

FlowSpec and Junos

Configuring FlowSpec on a JunOS device is actually quite straightforward. I’m being naughty and I don’t actually have a topology set up to show the full verification ‘show command’ outputs on the cli, but when I get the time to set something up, I’ll be back to edit this post. With all that said, Let’s getting cracking :p

The scenario is that we have an attack from on TCP port 80 to the web-server First we will inject a FlowSpec route to discard all TCP port 80 traffic to when the source is from We will need to make sure that we can order the terms as per the RFC requirement, this is done under the show routing-options flow stanza:

[email protected]# show routing-options flow                       
term-order standard;

Then enable MP-BGP family flow to BGP group

[email protected]# show protocols bgp group test 
type internal;
family inet {

Next configure the FlowSpec Route under routing-options flow route stanza:

[edit routing-options flow route test]
[email protected]# show 
match {
    protocol tcp;
    port 80;
then discard;

With these are the options available under match and then flags. You will note that they are largely the same flags that were stated in the RFC

Match FlagsThen Flags
[edit routing-options flow]
[email protected]# set route test match ?  
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  destination          Destination prefix for this traffic flow
+ destination-port     Destination TCP/UDP port
+ dscp                 Differentiated Services (DiffServ) code point (DSCP) (0-63)
+ fragment             
+ icmp-code            ICMP message code
+ icmp-type            ICMP message type
+ packet-length        Packet length (0-65535)
+ port                 Source or destination TCP/UDP port
+ protocol             IP protocol value
  source               Source prefix for this traffic flow
+ source-port          Source TCP/UDP port
+ tcp-flags            TCP flags
[edit routing-options flow]
[email protected]# set route test then ?                          
Possible completions:
  accept               Allow traffic through
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  community            Name of BGP community
  discard              Discard all traffic for this flow
  next-term            Continue the filter evaluation after matching this flow
  rate-limit           Rate in bits/sec to limit the flow traffic (9600..1000000000000)
  routing-instance     Redirect to instance identified via Route Target community
  sample               Sample traffic that matches this flow

Once committed you will be able to verify Flowspec routes because they are installed into their own routing table inetflow.0 and if dedicated, VRF for FlowSpec routes and the table will be under routing-instance-name.inetflow.0. You can also check FlowSpec firewall filter by running the command show firewall filter __flowspec_default_inet__

FlowSpec TableFlowSpec Firewall Filter
[email protected]> show route table inetflow.0 extensive 

inetflow.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden),,proto=6,port=80/term:3 (1 entry, 1 announced)
KRT in dfwd;
Action(s): discard,count
        *Flow   Preference: 5
                Next hop type: Fictitious
                Address: 0x94359c4
                Next-hop reference count: 6
                Local AS: 65123 
                Age: 4:10 
                Validation State: unverified 
                Task: RT Flow
                Announcement bits (1): 0-Flow 
                AS path: I
                Communities: traffic-rate:0:0
[email protected]> show firewall filter __flowspec_default_inet__    

Filter: __flowspec_default_inet__                              
Name                                                Bytes              Packets,,proto=6,port=80                    0                    0
Share this: