Monday, August 21, 2017

BGP Path Selection by Origin Code

Origin code is the fifth BGP attribute in the list.. There are three origin codes you could see in the BGP table..

i - IGP for the networks you advertised using network command of BGP
e - EGP for an old routing protocol which is no longer used
? - Incomplete for the redistributed routes into BGP

Precedence comes like i > e > ? 
Because e is no longer seen,

i > ? , BGP advertised routes are preferred over redistributed routes..

Let's see an example..




















Basic BGP configuration is like the following..

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 remote-as 2
R1(config-router)#neighbor 192.168.13.3 remote-as 2

R2(config)#router bgp 2
R2(config-router)#neighbor 192.168.12.1 remote-as 1
R2(config-router)#network 10.10.10.0 mask 255.255.255.0
R2(config-router)#network 20.20.20.0 mask 255.255.255.0

R3(config)#router bgp 2
R3(config-router)#neighbor 192.168.13.1 remote-as 1
R3(config-router)#redistributed connected

Both 10.10.10.0/24 & 20.20.20.0/24 networks are advertised from R2 by the network command while same networks are redistributed to the BGP process by R3. Let's see the BGP table of R1..













You can see that for both the networks, R2's route has become the best route because of their origin code is 'i'.

Side Note:- Because I just redistributed all the connected routes in R3, you can see 192.168.13.0/24 is in BGP table and it is selected as the best route. But note the 'r' in front of the '>' mark. Which means a RIB failure. This is because 192.168.13.0/24 is connected to R1, it will not add the BGP route to routing table. You can verify it by looking the routing table of R1..




Customizing ITIL Framework for a Small Network Operations Center

Adapting a best practice framework is crucial to improve the quality of any IT service delivered to a customer. There are some well known frameworks designed to meet business requirements.

You can use one of them which suits for your organization and do some adjustments / customization if needed. 

The framework we chose to implement is ITIL (Information Technology Infrastructure Library) which was developed in United Kingdom around late 90's and currently at its version 3 which is used by many companies around the world. I have done some customization to this version of ITIL to match the NOC I work and currently we are adapting to this new framework.. If you are working in a small NOC too, you will be able to implement ITIL in your work place after reading this.. 

The NOC I work is a small technical team which consists about 8 engineers including the Team Leader. We have the Help Desk function & the L1 / L2 support functions. We give onsite support as a 3rd party contractor to the national airline @ an international airport. What we do here mostly resides in 2 stages (Service Transition & Service Operation) out of 5 stages of ITIL. These stages group processes which we should follow..

Five Stages of ITIL are as following;

(1) Service Strategy
(2) Service Design
(3) Service Transition
(4) Service Operations
(5) Continuous Service Improvement

Service Transition is the implementation stage while Service Operation is the monitoring & support stage.. To simplify work, I merged 2 function roles in Service Operation stage with 2 process management roles in Service Transition stage so that they can operate in both these stages. 

New roles introduced:

(1) IT Operations Control & Deployment Manager
(2) Knowledge & Technical Manager

Database Components in SKMS (Service Knowledge Management System) are as following..

(1) CMDB - Changes Management Database (new)
(2) KMDB - Knowledge Management Database (new)
(3) SADB - Service Assets Database (Inventory)
(4) LMDB - Licenses Management Database (new)
(5) STDB - Service Testing Database (new)
(6) AEDB - Alerts & Events Database
(7) IRDB - Incident Records Database
(8) KEDB - Known Errors Database

As you can see, some databases are newly introduced while some databases are dropped from original ITIL framework..

Processes of Service Transition Stage

Change Management Process
Process Owner: Change Manager
Databases Maintained: CMDB (Changes Management Database)
Responsibilities: This guy is responsible  for all the changes happening in the network.
- Creates RFCs/CRs
- Plan maintenance windows
- Create change schedules communicating with CAB (Change Advisory Board)
- Categorize changes (standard, normal, emergency)

Knowledge Management Process
Process Owner: Knowledge & Technical Manager
Databases Maintained: KMDB (Knowledge Management Database)
Responsibilities: This guy is responsible for the knowledge sharing and technical consultancy.
 - Educate other team members
 - Design SKMS
 - Maintain network diagrams
 - Give technical solutions for all technical matters

Service Assets & Configurations Management Process
Process Owner: Service Assets & Configurations Manager
Databases Maintained: SADB (Service Assets Database), LMDB (Licenses Management Database)
Responsibilities: This guy is responsible for maintaining the network devices.
 - Keep the inventory up to date
 - Deal with RMAs
 - Carryout Audits
 - Managing software & hardware licenses
 - Make sure device accessability
 - Maintain access rights
 - Backup configurations

Release & Deploy Management Process
Process Owner: IT Operations Control & Deploy Manager (Team Lead Engineer)
Databases Maintained: n/a
Responsibilities: This guy is responsible for the deployment of the technology.
 - Choose the technical team and lead them in implementation

Service Validation & Testing Management Process
Process Owner: Service Validation & Testing Manager
Databases Maintained: STDB (Service Testing Database)
Responsibilities: This guy is responsible for the resiliency of the network.
 - Prepare test cases
 - Perform tests
 - Produce test report
 - Prepare user acceptance

Processes & Functions of Service Operations Stage

Alerts& Events Management Process
Process Owner: Alerts & Events Manager
Databases Maintained: AEDB (Alerts & Events Database)
Responsibilities: This guy is responsible for the proactive monitoring of the network.
 - Maintain monitoring tools
 - Inform about the issues to attend

Incidents Management Process
Process Owner: Incidents Manager
Databases Maintained: IRDB (Incident Records Database)
Responsibilities: This guy is responsible to operate the help desk & all the incident matters.
 - Logging issues
 - Deal with Service Desk
 - Handle customer employees
 - Escalate issues to relevant parties

Problems Management Process
Process Owner: Problems Manager
Databases Maintained: SADB (Service Assets Database), LMDB (Licenses Management Database)
Responsibilities:
 - Analyzing and diagnosing the problems (recurring issues)
 - Execute root cause analysis

IT Operations Control Management Function
Role:  IT Operations Control & Deploy Manager (Team Lead Engineer)
Responsibilities: This guy is responsible for supporting & coordinating all the day to day work.

Technical Management Function
Role: Knowledge & Technical Manager
Responsibilities: This guy is responsible for giving technical consultancy for all day to day issues.

Here are all the processes / functions and roles for both Service Transition & Service Operations Stages. (click on the image to view in full size)
























You can see the newly introduced IT Operations Control & Deployment Manager and Knowledge & Technical Manager resides in both the stages. Those are the 2 guys who should be contacted by the relevant managers for basically every issue which occurs through other processes.

You will have also noticed that there are some newly added databases and change of some duties assigned to manager roles. Those above are the customization I have done to the original framework.

First image source: https://www.pinterest.com

Friday, August 18, 2017

BGP Path Selection by AS-Path

AS-Path is the 4th BGP attribute in the list..

(1) Can use to influence routing in eBGP neighbors..
(2) Route with the shortest AS-Path is better..

Normally this is the real attribute which is by default working on Internet.. However we can manipulate the traffic by prepending the AS path.. Which means we can add our own AS number multiple times so the AS-path becomes longer. From this method we can tell eBGP neighbors to send the traffic to specific routes from the path we need.

Let's see an example..





















Basic routing (EIGRP) configurations in AS-1

R1(config)#router eigrp 10
R1(config-router)#network 192.168.12.0
R1(config-router)#network 192.168.13.0
R1(config-router)#network 1.0.0.0

R2(config)#router eigrp 10
R2(config-router)#network 192.168.12.0
R2(config-router)#network 2.0.0.0

R3(config)#router eigrp 10
R3(config-router)#network 192.168.13.0
R3(config-router)#network 3.0.0.0

Basic routing (static) on R1 to reach the R2-R4 & R3-R4 links

R1(config)#ip route 192.168.24.0 255.255.255.0 192.168.12.2
R1(config)#ip route 192.168.34.0 255.255.255.0 192.168.13.3

Basic BGP configurations

R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 remote-as 1
R1(config-router)#neighbor 2.2.2.2 update-source Loopback0
R1(config-router)#neighbor 3.3.3.3 remote-as 1
R1(config-router)#neighbor 3.3.3.3 update-source Loopback0

R2(config)#router bgp 1
R2(config-router)#neighbor 1.1.1.1 remote-as 1   
R2(config-router)#neighbor 1.1.1.1 update-source lo0
R2(config-router)#neighbor 3.3.3.3 remote-as 1           
R2(config-router)#neighbor 3.3.3.3 update-source lo0
R2(config-router)#neighbor 192.168.24.4 remote-as 2
R2(config-router)#network 192.168.12.0 mask 255.255.255.0
R2(config-router)#network 192.168.13.0 mask 255.255.255.0

R3(config)#router bgp 1
R3(config-router)#neighbor 1.1.1.1 remote-as 1
R3(config-router)#neighbor 1.1.1.1 update-source lo0
R3(config-router)#neighbor 2.2.2.2 remote-as 1       
R3(config-router)#neighbor 2.2.2.2 update-source lo0
R3(config-router)#neighbor 192.168.34.4 remote-as 2
R3(config-router)#network 192.168.12.0 mask 255.255.255.0
R3(config-router)#network 192.168.13.0 mask 255.255.255.0

R4(config)#router bgp 2
R4(config-router)#neighbor 192.168.24.2 remote-as 1
R4(config-router)#neighbor 192.168.34.3 remote-as 1

In red lines, you can see that I have advertised R1-R2 & R1-R3 links in both R2 & R3. This is possible since R2 and R3 has valid routes to those subnets in their routing tables.

Now let's see what R4 can see..














Because of the Metric values, the best path to 192.168.12.0 is chosen through R2 & the best path to 192.168.13.0 is chosen through R3..

This means that the routers in AS-2 sends traffic to R2 to reach 192.168.12.0 network and sends traffic to R3 to reach 192.168.13.0 network..









From AS-1, we can change the routing of AS-2 router (R4) by using route maps..

Here is how to change the routing path to 192.168.12.0 network..

R2(config)#access-list 10 permit 192.168.12.0 255.255.255.0

R2(config)#route-map AS-PATH-R2 permit 10
R2(config-route-map)#match ip address 10
R2(config-route-map)#set AS-path prepend 1 
R2(config-route-map)#route-map AS-PATH-R2 permit 20

R2(config-route-map)#router bgp 1
R2(config-router)#neighbor 192.168.24.4 route-map AS-PATH-R2 out 












Now you can see that the path is changed in R4. Notice that the Path is 1 1 i through R2 and it is 1 i through R3. We only added one "1" in the route map, the other 1 came from the default behavior. You can see even the Metric is large, path from R3 is preferred because AS-Path comes before Metric in BGP..

You can tweek the route to 192.168.13.0 from R3 using a route map too.

Note:- This is pointless to be used with iBGP neighbors because they do not update the AS path..
The AS number use to prepend must be the router's AS number. Cannot use any arbitrary number..
Also this can be used both inbound & outbound routing updates to an eBGP neighbor..