Apart from general traffic engineering via link colouring and modifying strict path for a colourless LSP, we can have a unique use case where we would like to send l3vpn traffic for a specific customer via a specific LSP not preferred by general traffic.

rsvp mpls

For example, all traffic from PE5 to PE1 uses the gold coloured LSP, but we want a specific customer vrf to use another LSP which might take the path PE5-PE6-PE4-PE2-PE1. This usecase can arise due to multiple reasons, sometimes, its the cost of certain links which are premium and you would like to send specific traffic for specific customers that pay premium rates through those links only.

To achieve this, we need to configure RSVP to ensure all traffic from PE5 Customer A L3VPN utilises a new LSP built between PE5 and PE1 for this purpose, separate from the gold LSP.

The process for this involves the following:

  • Assign a fake address to PE1 and advertise it as the next hop along with the route target for Customer A L3VPN.
  • At PE5, signal a new LSP that terminates at PE1 with the FAKE next-hop address assigned and advertised by PE1.
  • Modify the import policy for Customer A L3VPN to import the route target with the fake next-hop only.

Once the above is configured, we will be able to see Customer A send all it’s traffic via the newly signalled LSP.

Route table for l3vpn customer_A before l3vpn traffic engineering:

[email protected]# run show route logical-system PE5 table customer_A
customer_A.inet.0: 17 destinations, 31 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, -- = Last Active, * = Both *[BGP/170] 6d 01:27:08, localpref 100, from
AS path: 65300 13000 I, validation-state: unverified
> to via lt-0/0/10.11, label-switched-path PE5-to-PE2-Gold
to via lt-0/0/10.10, label-switched-path PE5-to-PE2-Gold *[BGP/170] 6d 03:08:13, localpref 100, from
[BGP/170] 6d 01:42:12, localpref 100, from
AS path: 65300 13000 I, validation-state: unverified
> to via lt-0/0/10.11, label-switched-path PE5-to-PE1-Gold
to via lt-0/0/10.10, label-switched-path PE5-to-PE1-Gold

Route table for l3vpn customer_A after l3vpn traffic engineering:

[email protected]# run show route logical-system PE5 table customer_A
customer_A.inet.0: 17 destinations, 31 routes (17 active, 0 holddown, 12 hidden)
+ = Active Route, -- = Last Active, * = Both *[BGP/170] 00:00:01, localpref 100, from
AS path: 65300 13000 I, validation-state: unverified
> to via lt-0/0/10.11, label-switched-path X-SERVICE-TO-PE1

With this implementation, all other L3VPNs on PE5 will continue to use the standard gold lsp, whereas l3vpn customer_A would use X-SERVICE-TO-PE1 LSP.

Configuration on PE5:

Configuration on PE1:


ARP requests and EVPN table population in leaf/spine data centre fabric


The advantage of using EVPN is the ability to extend layer 2 over a layer 3 fabric without the use of a SDN controller. This way we intend to get the flexibility of hosting any host belonging to any subnet behind any leaf switch and still form part of the same network by overlaying its layer 2 information over IP.

Refer to the topology below:



In a standard layer 2 deployment, we would have to span the vlan Customer Server A and Customer Server B are part of to ensure they are part of the same broadcast domain.

However, in the new leaf/spine based IP fabric deployment, we are going to advertise the layer 2 reachability information via EVPN over BGP.

We are going to achieve this by encapsulating the vlan customers are part of into a VNI which will be an additional tag that would be placed on top of the standard frame. The only thing we have to ensure is both servers on different leaf switches, whatever vlan they are part of, should be bridged to the same VNI. Vlans are only locally unique to the leaf switch.

Once the necessary configuration has been applied, the traffic work flow would be as follows:

Customer Server A would send an arp request to leaf05 which would be a broadcast request with a ff.ff.ff.ff type destination mac address. This broadcast packet when received by leaf05 would be sent to all local ports that are part of the same vlan by means of traditional layer 2 broadcast and all other leaf switches that have a valid VTEP configured over IP. A VTEP is a virtual tunnel IP which is the same as the loop back address. All layer 2 overlay traffic is sent and received between VTEPs over IP. The only difference here on wards would be that the broadcast packet would be forwarded over ip multicast instead to other VTEPs.

In this example, we have already established BGP as the underlying IP fabric so all VTEPs, i.e. leaf switches loopback addresses are already present in the routing table of each leaf switch.

The broadcast packet would then be encapsulated with the associated VNI tag and forwarded to all other VTEPs. Once received by other leaf switches, if the VNI is locally configured on a leaf switch, it would strip the vni tag and forward the frame to all ports that are associated to that VNI.

The ARP request was intended for Customer Server B which had IP configured on it. Therefore, every host that receives that ARP request would discard it apart from Customer Server B. Customer Server B would formulate an ARP reply based on the destination mac address of Customer Server A which was found in the ARP request. This reply would be forwarded to leaf08 which would already know the destination mac address of Customer Server A as it made an entry of the mac address and associated it with the ip address along with the next hop address of leaf05 it was advertised from.

The packet is then forwarded to leaf05’s VTEP address and leaf05 would perform the same function upon receiving the packet as leaf09 did and forward the frame to Customer Server A.

This way, our mac address overlay table is populated with the mac addresses of Customer Server A and Customer Server B on leaf05 and leaf09. Moreover, all leaf switches that received the broadcast ARP packet initially sent would now know the mac address of Customer Server A and the next hop associated to it.

Cumulus configuration snippets:

Following is a snippet of physcial interface vlan and vlan bridging along with the vni config over a cumulus linux switch:


Mac addresses learnt via evpn from other leaf switches:

[email protected]:mgmt-vrf:~$ net sh evpn mac vni
<1-16777215> : An integer from 1 to 16777215
all : Run a command on all connected hosts
[email protected]:mgmt-vrf:~$ net sh evpn mac vni all
VNI 10200 #MACs (local and remote) 5
MAC Type Intf/Remote VTEP VLAN
00:03:00:11:11:07 remote
00:03:00:11:11:06 remote
00:03:00:11:11:08 remote
00:03:00:11:11:05 local swp1 200
44:38:39:00:02:1c local vlan200 200

A quick look at the global evpn table yields the ip addresses associated with those mac addresses and the AS path to reach the VTEPs on the destination leaf switches:

[email protected]:mgmt-vrf:~$ net sh bgp l2vpn evpn route
BGP table version is 5, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i -- internal
Origin codes: i -- IGP, e -- EGP, ? -- incomplete
EVPN type-2 prefix: [2]:[ESI]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[ESI]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
*> [2]:[0]:[0]:[48]:[00:03:00:11:11:06]:[32]:[] 0 4200003000 4200001005 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:06]:[32]:[] 0 4200003000 4200001005 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:06]:[32]:[] 0 4200003000 4200001005 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:06]:[32]:[]
*> [2]:[0]:[0]:[48]:[00:03:00:11:11:07]:[32]:[] 0 4200003000 4200001006 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:07]:[32]:[] 0 4200003000 4200001006 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:07]:[32]:[] 0 4200003000 4200001006 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:07]:[32]:[] 0 4200003000 4200001006 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:08]:[32]:[] 0 4200003000 4200001007 i
*> [2]:[0]:[0]:[48]:[00:03:00:11:11:08]:[32]:[] 0 4200003000 4200001007 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:08]:[32]:[] 0 4200003000 4200001007 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:08]:[32]:[] 0 4200003000 4200001007 i

Pinging from Server behind leaf05 to server behind leaf08:

[email protected]:~$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=5.06 ms
64 bytes from icmp_seq=2 ttl=64 time=3.30 ms
--- ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 3.304/4.182/5.061/0.880 ms

Basics of a leaf/spine based IP Fabric architecture


Refer to the topology below:


The basic summary of the architecture is as follows:


All leafs are expected to form a BGP relationship with all spines (max 4) and each leaf will have a spine between them and any other leaf.

If using cumulus linux based switches, this BGP relationship would be based on BGP un-numbered.


Ethernet VPN would be responsible for sharing mac addresses between the leafs via the spines. This way each leaf will have the full mac view of all leafs to than proceed and emulate layer 2 over layer 3 via the use of VXLANs.

The underline mechanism is straight forward, i.e. use MP-BGP to advertise all mac addresses from a leaf to all spines and than redistribute from spines to all other leafs.


VXLAN is just the name of the protocol, in reality, it is VNIs that create unique tunnels over the IP fabric. VNIs are responsible for inter-connecting all access ports from any leaf to all other access ports with the same vlan on all other leafs.

This way we would achieve layer 2 transportation over layer 3 with the added flexibility of stretching any vlan across all leafs, assigning multiple vlans to the same VNI and keeping the same broadcast domain (will become multicast over IP) whilst getting rid of STP and making use of all available ports


This in a nutshell is the basic workflow of the modern data centre where layer 2 is over layed over IP with the use of VXLANs.

What is EVPN?


In a Leaf/Spine topology, Ethernet VPN or EVPN is predominantly used to carry mac addresses between leaf switches. These mac addresses belong to all servers attached to leaf switches.

Since bgp unnumbered runs between all leaf, spine and exit switches, all we really do is specify an l2vpn evpn based address family under BGP and proceed to advertise all layer 2 information from each vni into it. We can also choose to reduce this to specific vni’s if we prefer but in our design we intend to advertise all vni’s on each leaf switch so that the layer 2 reachability information is passed and forwarded to each member of the bgp fabric, i.e. other leaf switches, spines and exits.

This way, all subsequent network switches than have an evpn table can refer to it in order to forward frames they receive that want to go out to a destination mac address that lives on another leaf switch in the topology.

Cumulus configuration example to advertise all vni’s into evpn:

The above configuration snippet is defined under bgp which enables evpn and advertises all mac addresses learnt locally to bgp peers which in the case of a leaf switch would be all spine switches it is peered with (usually four).

A look at the leaf’s evpn table yields the following:

[email protected]:mgmt-vrf:~$ net sh bgp l2vpn evpn route
BGP table version is 5, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i -- internal
Origin codes: i -- IGP, e -- EGP, ? -- incomplete
EVPN type-2 prefix: [2]:[ESI]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[ESI]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
* [2]:[0]:[0]:[48]:[00:03:00:11:11:05]:[32]:[] 0 4200003000 4200001004 i
*> [2]:[0]:[0]:[48]:[00:03:00:11:11:05]:[32]:[] 0 4200003000 4200001004 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:05]:[32]:[] 0 4200003000 4200001004 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:05]:[32]:[] 0 4200003000 4200001004 i
[2]:[0]:[0]:[48]:[00:03:00:11:11:08]:[32]:[] 0 4200003000 4200001007 i
*> [2]:[0]:[0]:[48]:[00:03:00:11:11:08]:[32]:[] 0 4200003000 4200001007 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:08]:[32]:[] 0 4200003000 4200001007 i
* [2]:[0]:[0]:[48]:[00:03:00:11:11:08]:[32]:[]

In the example above, you can see that leaf01 learns about the mac addresses of the destination ip and via EVPN. It also learns about the next-hop address which is for and for

These next-hop addresses don’t belong to directly connected neighbours, however, a quick look at the global routing table helps us resolve the next-hop address:

[email protected]:mgmt-vrf:~$ net sh route
show ip route
Codes: K -- kernel route, C -- connected, S -- static, R -- RIP,
O -- OSPF, I -- IS-IS, B -- BGP, E -- EIGRP, N -- NHRP,
T -- Table, v -- VNC, V -- VNC-Direct, A -- Babel, D -- SHARP,
F -- PBR,
> -- selected route, * -- FIB route
C>* is directly connected, lo, 1d01h38m
B>* [20/0] via fe80::4638:39ff:fe00:28b, swp52, 1d01h38m
* via fe80::4638:39ff:fe00:4bb, swp49, 1d01h38m
* via fe80::4638:39ff:fe00:3bf, swp50, 1d01h38m
* via fe80::4638:39ff:fe00:3b, swp51, 1d01h38m
B>* [20/0] via fe80::4638:39ff:fe00:28b, swp52, 1d01h38m
* via fe80::4638:39ff:fe00:4bb, swp49, 1d01h38m
* via fe80::4638:39ff:fe00:3bf, swp50, 1d01h38m
* via fe80::4638:39ff:fe00:3b, swp51, 1d01h38m
B>* [20/0] via fe80::4638:39ff:fe00:28b, swp52, 1d01h38m
* via fe80::4638:39ff:fe00:4bb, swp49, 1d01h38m
* via fe80::4638:39ff:fe00:3bf, swp50, 1d01h38m
* via fe80::4638:39ff:fe00:3b, swp51, 1d01h38m
B>* [20/0] via fe80::4638:39ff:fe00:28b, swp52, 1d01h38m
* via fe80::4638:39ff:fe00:4bb, swp49, 1d01h38m
* via fe80::4638:39ff:fe00:3bf, swp50, 1d01h38m
* via fe80::4638:39ff:fe00:3b, swp51, 1d01h38m
B>* [20/0] via fe80::4638:39ff:fe00:28b, swp52, 1d01h38m
* via fe80::4638:39ff:fe00:4bb, swp49, 1d01h38m
* via fe80::4638:39ff:fe00:3bf, swp50, 1d01h38m
* via fe80::4638:39ff:fe00:3b, swp51, 1d01h38m
B>* [20/0] via fe80::4638:39ff:fe00:28b, swp52, 1d01h38m
* via fe80::4638:39ff:fe00:4bb, swp49, 1d01h38m
* via fe80::4638:39ff:fe00:3bf, swp50, 1d01h38m
* via fe80::4638:39ff:fe00:3b, swp51, 1d01h38m
B>* [20/0] via fe80::4638:39ff:fe00:28b, swp52, 1d01h38m
* via fe80::4638:39ff:fe00:4bb, swp49, 1d01h38m
* via fe80::4638:39ff:fe00:3bf, swp50, 1d01h38m
* via fe80::4638:39ff:fe00:3b, swp51, 1d01h38m

Any intended packet that wants to reach or would be forwarded to these ipv6 neighbours which are the spine switches. The spine switches would then forward the packet to the leaf switches advertising these mac addresses in similar fashion.

This in a nutshell is how we overlay layer 2 over layer 3 using EVPN.


SD-WAN – What is it?


SD-WAN. What is it? Should I care? Is it a standard? Why would I want to software define my WAN?! Let’s get to it…


You would have seen or heard SD-WAN if you work in IT, it is a hot topic and honestly, it has many definitions which can be confusing. SD-WAN is not a standard, so vendors and providers use it as a marketing term. I want to demystify the marketing with this post.


SD-WAN is an evolution in branch connectivity. It is intelligence at the edge of the network to leverage multiple links, load balance and monitor the performance of each, as well as application awareness. The technology is built into appliances, which there are many! Ok, yes, that was basically marketing, let me break it down.


If you think about your WAN currently, it is likely a mix of direct internet access (DIA), ADSL, 4G, MPLS, IPSsec VPNs… there are so many ways to connect! You may also have different edge devices too, a router, firewall, or from a switch. You will also have a process to handle a connectivity failure at a site. One of the challenges with office connectivity, or building a WAN, is resilience. There are many ways to achieve this, both physically and logically. A backup circuit, IP SLA, or a floating static route, some of these solutions are complex and over-engineered.


One of the features of SD-WAN overcomes this problem. Utilising all of the links available at a site, with real-time monitoring of each and steering traffic down the ‘best’ for specific types of traffic. For example, which of my available links is the best for voice traffic? Which has the lowest latency to a destination? and so on… the devices are constantly probing the links to determine the best – insight into the quality of the link. It challenges circuit failover as all the links are in use, but you can  achieve sub-second failover for your IPSsec VPN.


SD-WAN appliances are also application/layer 7 aware. This means you have even more control to steer traffic, which of my available links is the best, lowest latency to Office365? As more and more applications move to the cloud, you realise why SD-WAN has so much traction.


However, arguably the main reason why SD-WAN is such a hot topic, is cost. You can significantly reduce WAN spend by deploying an SD-WAN solution, because instead of paying for expensive links, with SLAs, you can replace them with commodity/consumer links. This is also the reason it is compared with MPLS, they are very different offerings but ultimately, you will be able to connect and office for less with SD-WAN, when compared with MPLS.


I hope that has helped you understand SD-WAN, a very brief overview! I will write a follow up. We will deep dive into SD-WAN vs MPLS at a lower level, I’ll also go through SD-WAN deployments/topologies, as well as the appliance offerings!

BGP Unnumbered


Successful Leaf/Spine deployment is entirely dependent on BGP which forms the underlying foundation of the IP based fabric as our intention is to provide layer 2 as an overlay service running on top of layer 3.

To run BGP unnumbered, the following configuration should be enough on cumulus leaf switches:

Great thing about BGP un-numbered as the name suggests is you don’t need to specify ip addresses and you just have to specify the interface you want BGP un-numbered to run and as long as the remote end has similar configuration, the sessions should come up.

BGP unnumbered configuration on cumulus spines:

Since the spines peer with the leafs and exits via bgp unumbered, you can see all corresponding interfaces are part of the BGP unnumbered configuration.

The result is successful bgp peering with all leafs and exits seamlessly as seen below:

[email protected]:mgmt-vrf:~$ net sh bgp summary
show bgp ipv4 unicast summary
BGP router identifier, local AS number 4200003000 vrf-id 0
BGP table version 25
RIB entries 37, using 5624 bytes of memory
Peers 18, using 347 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
leaf01(swp1) 4 4200001000 30445 30380 0 0 0 1d01h14m 1
leaf02(swp2) 4 4200001001 30398 30380 0 0 0 1d01h14m 1
leaf03(swp3) 4 4200001002 30398 30380 0 0 0 1d01h14m 1
leaf04(swp4) 4 4200001003 30398 30380 0 0 0 1d01h14m 1
leaf05(swp5) 4 4200001004 30480 30380 0 0 0 1d01h14m 1
leaf06(swp6) 4 4200001005 30461 30380 0 0 0 1d01h14m 1
leaf07(swp7) 4 4200001006 30462 30380 0 0 0 1d01h14m 1
leaf08(swp8) 4 4200001007 30463 30380 0 0 0 1d01h14m 1
leaf09(swp9) 4 4200001008 30398 30380 0 0 0 1d01h14m 1
leaf10(swp10) 4 4200001009 30398 30380 0 0 0 1d01h14m 1
leaf11(swp11) 4 4200001010 30398 30380 0 0 0 1d01h14m 1
leaf12(swp12) 4 4200001011 30398 30380 0 0 0 1d01h14m 1
leaf13(swp13) 4 4200001012 30398 30380 0 0 0 1d01h14m 1
leaf14(swp14) 4 4200001013 30398 30380 0 0 0 1d01h14m 1
leaf15(swp15) 4 4200001014 30398 30379 0 0 0 1d01h14m 1
leaf16(swp16) 4 4200001015 30398 30379 0 0 0 1d01h14m 1
exit01(swp25) 4 4200502000 30583 30442 0 0 0 21:00:58 1
exit02(swp26) 4 4200502000 30398 30410 0 0 0 18:42:05 1
Total number of neighbors 18

BGP unumbered is one of the best tools I have come across in deploying an IP fabric. It totally removes the need for manual ip allocation/configuration as it relies on ipv6 link local addresses for point to point addressing.

Once you use Ansible to configure your leafs and spines, bgp unnumbered will bring up bgp as if you were running ospf in the fabric instead of bgp. This is largely thanks to static switchport configuration inside the bgp config.

How to become a CISSP (Certified Information System Security Professional) – Part two


Changing into a CISSP entails 4 distinct phases:

  • Meet Expertise Requirements
  • Move the Examination
  • Receive an Endorsement
  • Put together for an Audit


I had been planning for this certification for a very long time, however I couldn’t get an opportunity to dedicate some high quality time. Time continues to be a challenge so I took this six weeks’ strategy to organise and give it a shot. I count on you to deddicate 2-3 hours on weekdays and a couple of extra hours over the weekend.


CISSP examination might be cleared when you

  • Have the precise expertise
  • Know the “Terminologies” effectively


CISSP necessities mandate that its best to have minimal of 5 years of direct full-time safety work expertise in two or more of eight domains. That is essential. I found CISSP to be a really sensible examination. Many of the questions requested within the examination had been carefully associated to each day related to actions you observe to construct a safe atmosphere.


Now to cover the “know the terminology” half; observe the under strategy,

  • Learn “CISSP Research Information” by Eric Conrad (Three weeks)
  • You can see among the subject, some are very simple but a few of them are difficult. It’s best to determine your weaknesses and use “Shon Harris- Multi functional CISSP Research Information” to clear up on your ideas. It’s one of the greatest e-books obtainable on the subject of explaining essentially the most difficult of topics. you must learn this e-book cover by cover.
  • After ending every chapter of Eric Conard’s CISSP Research Information, take the examination at the end of EC & SH books and see your rating. I’d say in case if you are scoring higher than 70% within the first attempt; you might be in a fairly good position already!
  • Glossary (Three days) •Take a while to undergo the glossary behind the 2 books talked about above.
  • At this stage; it’s best to have a good understanding of the terminologies.
  • Apply for the exam (2 weeks) •Take the CCCure Quiz for CISSP – these exams give you a very realistic view of CISSP. You must be scoring >70% in these exams to stand a chance in the real world exam.
  • If you are going via the exams; take a while in between to learn Eleventh Hour CISSP: Research Information by Eric Conard – it’s a really brief e-book which helps you revise the core subjects in a brief span.
  • Ultimate Preparation (2 days) •You could have booked the examination and its your final 2 days. I’ve some brief notes that I used ultimately which summarises the entire course. If you contact me directly, I can share these with you.

Additionally, some material in the final examination isn’t lined up within the books talked about above. These are newest tendencies and applied sciences like Cloud, Cellular codes and so on. I used to be simply in a position to sort out these questions as you could have searching for these topics over the internet, conferences, roadshows & seminars etc. A couple of examples are:

  • What ought to your safety considerations be in case you are an internet hosting provider, is your content material on a Public Cloud?
  • What sort of SLA do you agree on from your Cloud provier?


The examination is now supplied by way of VUE so that you can provide it as per your comfort. Earlier it was a paper based examination held solely on couple of occasions in a twelve month period.


If you would like to ask any questions or need extra information on the subject, please do contact me directly at [email protected]


Hope the above will assist in your preparation. Good Luck!



How to become a CISSP (Certified Information System Security Professional) – Part One


This blog post is written to give you a brief overview of the benefits of CISSP and the best way to achieve the certification. I have been in the Network Security industry for more than 10 years. I started my career as a network field engineer and moved on to an analyst role then NOC, engineering, senior network security specialist to finally network security design/architect. I also acquired network certifications such as CCIE-SP and security based certifications based on Palo Alto and Juniper security devices. All certs were very vendor specific. Working as a network security designer/architect, I feel like I know much about network security but there are many aspects in any organisation where customer need a security layer with some of the domains which I was quite unfamiliar with.

CISSP, vendor-neutral cert, gave me an excellent exposure and a very good overview of IT (as a whole department where network security is a small part of it) posture of any organisation. It also covered many domains which were new to me like “Software Development Security”. In short, CISSP provides a necessary overall grasp of IT security.

ISC2 certifications are very different to any other traditional certifications. I would suggest you have a read through ISC2 certification pre-req before attempting to sit in for CISSP. In a quick glance, ISC2 need certain years of experience which need to be proved once you pass the exam in order to get certified.

Regardless if you want to get the certification or not, I would say read the contents of CISSP and you will realise how beneficial it is.

CISSP is designed to cover the following eight domains;

  • Security and Risk Management.
  • Asset Security.
  • Security Architecture and Engineering.
  • Communications and Network Security.
  • Identity and Access Management.
  • Security Assessment and Testing.
  • Security Operations.
  • Software Development Security.

From the above domains, I always thought I would be fine on communication and Network Security but CISSP covered this domain very differently. Yes I know that domain is the principle of Network Security, but I learnt a lot because CISSP’s perspective about this domain is on a totally different level.

My next blog will focus on how to get CISSP certification in 8 weeks (subject to the right experience) based on my own experience. I will also share resources (books, online resource, etc.) that I found very useful.

How to see advertised and received routes via BGP neighbours


When you pass the show ip route command on a cisco router, you are presented with the routing table of the router. This table comprises of the best routes the router has chosen as the primary routes.


sh ip route
Codes: L -- local, C -- connected, S -- static, R -- RIP, M -- mobile, B -- BGP
D -- EIGRP, EX -- EIGRP external, O -- OSPF, IA -- OSPF inter area
N1 -- OSPF NSSA external type 1, N2 -- OSPF NSSA external type 2
E1 -- OSPF external type 1, E2 -- OSPF external type 2
i -- IS-IS, su -- IS-IS summary, L1 -- IS-IS level-1, L2 -- IS-IS level-2
ia -- IS-IS inter area, * -- candidate default, U -- per-user static route
o -- ODR, P -- periodic downloaded static route, H -- NHRP, l -- LISP
+ -- replicated route, % -- next hop override
Gateway of last resort not set is variably subnetted, 2583 subnets, 14 masks
B [20/7031] via, 2w0d
B [20/137121] via, 2w1d
B [20/137121] via, 2w1d
B [20/137121] via, 2w1d
B [20/137121] via, 2w1d
B [20/137121] via, 2w1d
B [200/0] via, 2w1d
B [200/0] via, 2w1d

However, If you want to see the routes received by BGP neighbours only along with key attributes such as AS Path and local preference etc, you can view the BGP routing table by using the show ip bgp command.


sh ip bgp
BGP table version is 9501588, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i -- internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i -- IGP, e -- EGP, ? -- incomplete
Network Next Hop Metric LocPrf Weight Path
*> 7031 4000 0 213964 13335 13335 i
*> 137121 4000 0 213964 4826 38803 56203 i
*> 137121 4000 0 213964 4826 38803 56203 i
*> 137121 4000 0 213964 4826 38803 56203 i
*> 137121 4000 0 213964 4826 38803 56203 i
*> 137121 4000 0 213964 4826 38803 56203 i
*>i1.0.16.0/24 0 4000 0 3356 2914 2519 i
*>i1.0.64.0/18 0 4000 0 3356 2516 7670 18144 i

Further to that, the show ip bgp summary command lists all BGP neighbours on the router.


sh ip bgp summary
BGP router identifier
BGP table version is 9501373, main routing table version 9501373
698513 network entries using 97791820 bytes of memory
1242345 path entries using 69571320 bytes of memory
295132/106926 BGP path/bestpath attribute entries using 37776896 bytes of memory
166524 BGP AS-PATH entries using 6137930 bytes of memory
72 BGP community entries using 1728 bytes of memory
149 BGP route-map cache entries using 5364 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 211285058 total bytes of memory
BGP activity 900150/201636 prefixes, 3945360/2703015 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 4 65177 7783 8563 9501373 0 0 5d09h 0 4 65122 22040 237883 9501373 0 0 2w1d 0 4 65133 2740502 1522137 9501206 0 0 2w1d 693452

To view which BGP neighbour is advertising which prefixes to you, you can use the show ip bgp neighbor <neighbour ip address> advertised-routes command:


sh ip bgp neighbors advertised-routes
BGP table version is 9505142, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i -- internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i -- IGP, e -- EGP, ? -- incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0 400 i
Total number of prefixes 1

To view what prefixes you are receiving from a given BGP neighbour, you can use the show ip bgp neighbor <neighbour ip address> received-routes command:


sh ip bgp neighbors received-routes
BGP table version is 9505142, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i -- internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i -- IGP, e -- EGP, ? -- incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0 400 i
Total number of prefixes 1

It’s important to remember that the show ip bgp neighbor <neighbor-ip> <advertised/received>-routes command only shows you the attributes of the route BEFORE it was manipulated by a route map (if configured). This command can cause a lot of confusion sometimes if not used with this in mind.

The output of the command shows the routes AS they were received and AS they were advertised before a route map was applied to manipulate BGP attributes.

How to deploy an office network like a Pro!


I have deployed many offices over the past decade. Some were complicated, others relatively straight forward. The common constraint in most of my deployments has always been time.

Usually new offices are always opened due to pressing business needs. This means, the higher management want to see staff moved/new recruits placed in the new office ASAP. Often I have found myself deploying offices on single links.

Every time, I wanted to deploy an office, I had to replicate existing process with minimal time to upgrade the tech involved. I always wanted to improve the network deployment but I always found myself running against time.

Office deployments are usually painful because after doing them the first time, you will find yourself not learning anything new in each successful deployment. You will, however, find yourself wasting a lot of time doing the same thing all over again. This lost time could be better utilized to other things such as improving the production network etc.

This all changed when I joined a company that gave me some breathing room and allowed me to improve the processes in place. This was a multi-billion dollar enterprise that was growing fast. I was already designing their new MPLS network so I realised an automated office network delivery mechanism would sync in really well.

How I managed to achieve this?

Follow my guide below to replicate the same for your next deployment and reduce the required time for all your subsequent deployments.

Config automation via Ansible:

The first thing I did was to automate configuration management with the use of Ansible. If you haven’t used Ansible before, you haven’t lived!

I used to write lengthy scripts in Perl and Python that would simply spit out configuration and change variables where intended. Writing those long print statements and spending countless hours, little did I know that I could achieve the same with Ansible in a matter of minutes!

As they say, it’s never too late, I jumped the Ansible bandwagon and automated all configuration deployment for successive deployments in future.

This meant, the usual components of an office deployment were all templated. These components included the following:

  1. Firewall configuration
  2. Core switch configuration
  3. Access switch configuration
  4. Production firewall rule sets configuration

Usually any office deployment involves the deployment of a branch firewall, core switch, multiple access switches and the configuration of rule sets over the corporate/production network firewalls in the data centre.

I configured Jinja templates which are simple YAML files for Ansible to manipulate for all devices listed above. This meant for each successive office, I simply had to update the variable files and the configuration for all the devices would churn out in a matter of seconds!

Ansible can actually go ahead and configure these devices for you as well but for new offices, the kit is still in boxes hence, you have to manually configure the devices via console. For existing firewalls in corporate/production network, you can easily task ansible to go and configure with the new rulesets/address addition in existing address objects.

If you want to follow me in automating your next office deployment via Ansible too, why not! than here’s a guide I have written for you: Ansible: Use playbook to deploy your next office

Securing the network using 802.1x:

In simple terms, 802.1x makes your ports secure by making the user authenticate against the active directory before allocating a vlan. This means if you are not an authorised user, you won’t get a vlan assigned on the port you are connected to. Moreover, security is further enhanced through the use of policy groups on the Network Policy Server (NPS). This means vlans can be associated with groups on active directory. To further elaborate this, consider the following scenario:

You have a dev/sysadmin or a network engineer on port gi1/0/35 on the switch with vlan 50 configured manually. This vlan has privileges to access almost all the resources on the network including key PCI or PII resources. It’s all fine if the right person is connected on that port. However, in case of a desk move, a marketing user can find himself connected on port gi1/0/35 with PCI level privileges. This is a considerable security risk as the first line of defence which is lack of reachability has just been broken. Anyone can connect on port gi1/0/35 and use hacked credentials of a privileged user and access PCI data. This might sound remote but it has happened before and corporations shouldn’t take risks like these that can damage their reputation and adversely affect business on a large scale.

802.1x has been around for a while now but a lot of business have shyed away from it predominantly because of negligence in their security model and the fact that it’s just not been high enough in their priority list. This, on top of laziness on part of the network team is usually to blame as 802.1x deployments are usually tedious and require a lot of troubleshooting to get it right. Therefore, instead of pushing this crucial port security method, a lot of times network engineers find it easier to pre-configure vlans on ports!

What most businesses don’t take into account is the overhead of network resources utilised upon port changes etc in the form of excessive tickets in the ticket queue. With 802.1x, you take all that hassle away and never have to worry about port moves performed by the desktop engineering teams.

I have to admit, whilst 802.1x was easy to understand (you can read the RFC here), it was one of the most painful deployments I have carried out to date.

The purpose of this post is NOT to scare you away but to encourage you to deploy 802.1x in your office network too.

I have gone through the hard work so you don’t have to. Most of the painful moments came whilst testing and trying to get the protocol to work properly in a lab environment.

I would highly recommend you go through the guides below and implement this in your office today.

MAB: Mac Authentication Bypass on 802.1x
NPS settings for Mac Authentication Bypass (MAB) using 802.1x
Microsoft Network Policy Server (NPS) configuration for 802.1x authentication using PEAP
802.1x (dot1x) configuration guide for cisco switches (Including IP Phones)

The guides are pretty self explanatory but in a nutshell, you have two kinds of devices in offices over a wired network. Ones that support EAP and others that don’t.

EAP is the protocol that is used to authenticate a device. A port configured using 802.1x simply discards all packets apart from EAP packets. It then authenticates the device by contacting the NPS and then dynamically allocates the correct vlan on the port. Devices that fall under this category are all your laptops that are osx, windows or linux based. Other devices might support 802.1x too and it’s best to check by following up with the vendor’s documentation.

Devices that don’t support 802.1x can use MAB, i.e. Mac Authentication Bypass. What MAB does is pickup the registered mac address on the port and try and authenticate with the NPS using that mac address instead of a userid/password with radius. Generally, best practice is to prioritize MAB on your port so that the switch tries to authenticate using MAB first before reverting to EAP. This way all devices with registered mac address on the NPS easily get a vlan assigned to them.

One important thing is you might have to turn 802.1x ON on end devices so that they can take part in the EAP process. Normally, as soon as you plugin and end device that is osx, windows or linux based, the NIC simply sends a broadcast dhcp request to the network and waits for a DHCP offer from the DHCP server. This would mean when the switch port is configured with 802.1x, it would listen for EAP packets only and discard ALL other traffic. This means, the end device has to take part in the 802.1x process. In my experiece, Linux and Osx detect 802.1x packets themselves and inform the user to end userid and password to authenticate with a prompt. If they don’t it’s a simple option in the network settings. Windows however, is a different ball game!

With Windows, you will have to change Wired AutoConfig to automatic and ensure the service is always in START state.

This can be achieved by searching for services from the start bar and selecting Wired AutoConfig in the window that opens up as shown below:


Once the wired AutoConfig tab opens up, simply start the service and set it to automatic to ensure it always runs upon boot.


This would now ensure the windows machine now takes part in 802.1x process. That said, most organizations are 90% windows and 10% other devices. Therefore, it would be better to make this change in your whole estate via the use of a GPO policy. If you are not incharge of managing the windows estate, than usually this falls under the windows team in your business who can help you with this.

There is a lot more to it than just a few paragraphs but if you refer to the guides and examples referred above, you should be able to test and deploy a working solution with ease.

Last but not least, Wifi deployment is pretty straight forward. You just have to create a similar policy to wired in the NPS and make your APs request 802.1x authentication for each SSID you want to perform 802.1x authentication on. This is pretty straight forward and in my experience is the easiest part of the whole cycle to implement but you have to follow the documentation provided by the vendor of your wireless Access Points to achieve that. The NPS policies on the other hand, stay the same as defined in the above guide.

The end result:

After implementing it all, I was simply blown away when it all came together on day one of the office going live. Almost all users reported seamless connectivity. All devices such as printers, cctv camera etc simply had a dynamic vlan assigned. I being the network engineer would get high privileges on each port I connected on! This was a much smoother deployment than any office I have deployed so far with Ansible being the icing on the cake.

Upon the next office deployment, I will simply churn out the configuration files within minutes and with all 802.1x NPS policies already configured and in place, I now have the ability to configure and deploy an office in ONE DAY!

Imagine the time this has freed up for me and the rest of the team to perform other tasks!

Happy Networking 🙂