Posted by1 month ago
Solved: I am new to BGP. I would like to better understand how the Cisco implementation of BGP calculates the weight attribute. I would also like to know how Local Preference is calculated/set. Per the BGP chapter in the Internetworking Technologies. The BGP Weight attribute is a Cisco Proprietary attribute that influences a router how to reach a certain prefix. The difference between Local Preference and Weight is that the former is propagated within an AS and the latter is router locally significant.
Over 16 years, SPOTO helped tens of thousands of candidates achieve their Cisco CCNA, CCNP, CCIE, CISSP certification. Subscribe us and get more news. The following is a technical article that will help you understand the BGP weight attribute in a network.
Cisco routers can use BGP weights to influence routers' choice of outbound routes. To this end, when the router receives the BGP update, the router can use the route map to selectively set a weight for each route, or set a weight for all learned contention routes, and select a route with a larger weight.
The weight is a proprietary attribute of Cisco, and the weight tells us how to exit the autonomous system. The most important path for the most weighted path is 0 to 65,535. By default, the learning path is 0 and the local injection path is 32,768. The weight is a partial attribute that is set when the inbound route is updated.
let us see the configuration:-
Topology:-
GOAL:
·configure the topology as per the diagram.
·configure the basic iBGP and EBGP peering using directly connected interfaces.
·advertise all the interfaces as per the topology
·configure the next-hop address should be the next router address
·configure router 4 to prefer exit path via router1 to reach all the networks.
R1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.1.1.1 YES NVRAM up up
Serial3/0 1.1.1.1 YES NVRAM up up
Serial3/3 4.1.1.2 YES NVRAM up up
Loopback0 11.0.0.1 YES NVRAM up up
Loopback1 11.0.1.1 YES NVRAM up up
Loopback2 11.0.2.1 YES NVRAM up up
Loopback3 11.0.3.1 YES NVRAM up up
R2#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 20.1.1.1 YES NVRAM up up
Serial3/0 1.1.1.2 YES NVRAM up up
Serial3/1 2.1.1.1 YES NVRAM up up
Loopback0 12.0.0.1 YES NVRAM up up
Loopback1 12.0.1.1 YES NVRAM up up
Loopback2 12.0.2.1 YES NVRAM up up
Loopback3 12.0.3.1 YES NVRAM up up
R3#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 30.1.1.1 YES NVRAM up up
Serial3/1 2.1.1.2 YES NVRAM up up
Serial3/2 3.1.1.1 YES NVRAM up up
Loopback0 13.0.0.1 YES NVRAM up up
Loopback1 13.0.1.1 YES NVRAM up up
Loopback2 13.0.2.1 YES NVRAM up up
Loopback3 13.0.3.1 YES NVRAM up up
R4#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 40.1.1.1 YES NVRAM up up
Serial3/2 3.1.1.2 YES NVRAM up up
Serial3/3 4.1.1.1 YES NVRAM up up
Loopback0 14.0.0.1 YES NVRAM up up
Loopback1 14.0.1.1 YES NVRAM up up
Loopback2 14.0.2.1 YES NVRAM up up
Loopback3 14.0.3.1 YES NVRAM up up
R1(config)#router bgp 65111
R1(config-router)#neighbor 1.1.1.2 remote-as 65111
R1(config-router)#neighbor 4.1.1.1 remote-as 65444
R1(config-router)#neighbor 1.1.1.2 next-hop-self
R1(config-router)#network 10.0.0.0
R1(config-router)#network 1.0.0.0
R1(config-router)#network 4.0.0.0
R1(config-router)#network 11.0.0.0 mask 255.255.255.0
R1(config-router)#no auto-summary
R1(config-router)#no synchronization
R2(config)#router bgp 65111
R2(config-router)#neighbor 1.1.1.1 remote-as 65111
R2(config-router)#neighbor 2.1.1.2 remote-as 65333
R2(config-router)#neighbor 1.1.1.1 next-hop-self
R2(config-router)#network 20.0.0.0
R2(config-router)#network 2.0.0.0
R2(config-router)#network 1.0.0.0
R2(config-router)#network 12.0.0.0 mask 255.255.255.0
R2(config-router)#no auto-summary
R2(config-router)#no synchronization
R3(config)#router bgp 65333
R3(config-router)#neighbor 2.1.1.1 remote-as 65111
R3(config-router)#neighbor 3.1.1.2 remote-as 65444
R3(config-router)#network 30.0.0.0
R3(config-router)#network 3.0.0.0
R3(config-router)#network 2.0.0.0
R3(config-router)#network 13.0.0.0 mask 255.255.255.0
R3(config-router)#no synchronization
R3(config-router)#no auto-summary
R4(config)#router bgp 65444
R4(config-router)#neighbor 3.1.1.1 remote-as 65333
R4(config-router)#neighbor 4.1.1.2 remote-as 65111
R4(config-router)#network 40.0.0.0
R4(config-router)#network 4.0.0.0
R4(config-router)#network 14.0.0.0 mask 255.255.255.0
R4(config-router)#network 3.0.0.0
R4(config-router)#no synchronization
R4(config-router)#no auto-summary
R1#show ip bgp summary
BGP router identifier 11.0.3.1, local AS number 65111
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.2 4 65111 14 13 14 0 0 00:06:21 7
4.1.1.1 4 65444 14 9 14 0 0 00:02:07 7
R2#show ip bgp summary
BGP router identifier 12.0.3.1, local AS number 65111
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 65111 13 14 14 0 0 00:06:56 7
2.1.1.2 4 65333 11 12 14 0 0 00:04:29 6
R3#show ip bgp summary
BGP router identifier 13.0.3.1, local AS number 65333
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.1.1.1 4 65111 13 12 14 0 0 00:05:27 9
3.1.1.2 4 65444 11 14 14 0 0 00:03:59 9
R4#show ip bgp summary
BGP router identifier 14.0.3.1, local AS number 65444
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
3.1.1.1 4 65333 14 12 21 0 0 00:04:25 10
4.1.1.2 4 65111 11 16 21 0 0 00:04:05 9
R4#sh ip bgp
BGP table version is 21, local router ID is 14.0.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 4.1.1.2 0 0 65111 i
* 3.1.1.1 0 65333 65111 i
* 2.0.0.0 4.1.1.2 0 65111 i
*> 3.1.1.1 0 0 65333 i
*> 3.0.0.0 0.0.0.0 0 32768 i
* 3.1.1.1 0 0 65333 i
*> 4.0.0.0 0.0.0.0 0 32768 i
* 4.1.1.2 0 0 65111 i
* 3.1.1.1 0 65333 65111 i
*> 10.0.0.0 4.1.1.2 0 0 65111 i
* 3.1.1.1 0 65333 65111 i
*> 11.0.0.0/24 4.1.1.2 0 0 65111 i
* 3.1.1.1 0 65333 65111 i
*> 12.0.0.0/24 4.1.1.2 0 65111 i
Network Next Hop Metric LocPrf Weight Path
* 3.1.1.1 0 65333 65111 i
* 13.0.0.0/24 4.1.1.2 0 65111 65333 i
*> 3.1.1.1 0 0 65333 i
*> 14.0.0.0/24 0.0.0.0 0 32768 i
*> 20.0.0.0 4.1.1.2 0 65111 i
* 3.1.1.1 0 65333 65111 i
* 30.0.0.0 4.1.1.2 0 65111 65333 i
*> 3.1.1.1 0 0 65333 i
*> 40.0.0.0 0.0.0.0 0 32768 i
R4#traceroute 30.1.1.1
Type escape sequence to abort.
Tracing the route to 30.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 3.1.1.1 168 msec 60 msec 24 msec
To reach the 30.1.1.1 router 4 by default using 3.1.1.1 interface because it has fewer numbers of AS.
but we want to router 4 go via 4.1.1.1 interface to reach all the networks.
R4(config)#router bgp 65444
R4(config-router)#neighbor 4.1.1.2 weight 20000
R4(config-router)#end
R4#clear ip bgp * soft
R4#traceroute 30.1.1.1
Type escape sequence to abort.
Tracing the route to 30.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 4.1.1.2 8 msec 56 msec 4 msec
2 1.1.1.2 [AS 65111] 52 msec 40 msec 36 msec
3 2.1.1.2 [AS 65111] 52 msec 40 msec 64 msec
R4#show ip bgp 30.1.1.1
BGP routing table entry for 30.0.0.0/8, version 22
Paths: (2 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 2
65111 65333
4.1.1.2 from 4.1.1.2 (11.0.3.1)
Origin IGP, localpref 100, weight 20000, valid, external, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 3
65333
3.1.1.1 from 3.1.1.1 (13.0.3.1)
Origin IGP, metric 0, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
R4#show ip bgp
R4#show ip bgp
BGP table version is 29, local router ID is 14.0.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 4.1.1.2 0 20000 65111 i
* 3.1.1.1 0 65333 65111 i
*> 2.0.0.0 4.1.1.2 20000 65111 i
* 3.1.1.1 0 0 65333 i
*> 3.0.0.0 0.0.0.0 0 32768 i
* 3.1.1.1 0 0 65333 i
*> 4.0.0.0 0.0.0.0 0 32768 i
* 4.1.1.2 0 20000 65111 i
* 3.1.1.1 0 65333 65111 i
*> 10.0.0.0 4.1.1.2 0 20000 65111 i
* 3.1.1.1 0 65333 65111 i
*> 11.0.0.0/24 4.1.1.2 0 20000 65111 i
* 3.1.1.1 0 65333 65111 i
*> 12.0.0.0/24 4.1.1.2 20000 65111 i
Network Next Hop Metric LocPrf Weight Path
* 3.1.1.1 0 65333 65111 i
*> 13.0.0.0/24 4.1.1.2 20000 65111 65333 i
* 3.1.1.1 0 0 65333 i
*> 14.0.0.0/24 0.0.0.0 0 32768 i
*> 20.0.0.0 4.1.1.2 20000 65111 i
* 3.1.1.1 0 65333 65111 i
*> 30.0.0.0 4.1.1.2 20000 65111 65333 i
* 3.1.1.1 0 0 65333 i
*> 40.0.0.0 0.0.0.0 0 32768 i
comment
The previous tutorials demonstrated how we can turn a CentOS box into a BGP router and filter BGP prefixes using Quagga. Now that we understand basic BGP configuration, we will examine in this tutorial how to perform more advanced traffic engineering on Quagga. More specifically, we will show how we can influence the routing path of existing traffic by tuning BGP attributes (e.g., local preference).
Routing and Path Selection
In a typical Internet environment where multiple routing paths exist from a source to a destination, the actual path taken by traffic is the result of diligent traffic engineering which involves multiple factors, including the number of router/AS hops in the path, bandwidth capacity, path reliability, congestion in the path, and so on.
To be more specific, a routing path chosen by traffic is shaped by individual routing decisions made by each intermediate router based on its local routing table. The routes stored in the routing table may be statically configured, learnt by IGP like OSPF or EIGRP, or learnt by BGP. A single route can be learnt by more than one protocol. In such a case, the preferred route depends generally on some protocol-specific attribute, for example, prefix length and administrative distance. In BGP world, we can influence path decision process by tuning BGP attributes such as local preference in BGP routers.
Please note that routing decisions influence forward traffic, i.e., outbound traffic that is originated by the router or transit traffic that is forwarded by the router.
Path Selection in BGP
In BGP, IPv4 and IPv6 prefixes are propagated globally over the Internet through prefix advertisements sent to and received from BGP neighbors. When multiple routes are received for a particular prefix, your local BGP router will make a decision to forward traffic destinted to that prefix via one of the routes. Similarly, a remote router will make its own routing decisions based on the prefixes that it learns from others, and some of those prefixes may be advertised by yourself. The remote router will send traffic to you if it chooses the route you advertised, as the best route for a given prefix.
If you notice closely, the relationship between prefix advertisements and traffic can be represented using the following diagram. You can see that the traffic flows in the opposite direction of the prefix advertisements.
BGP is one of the most highly customizable routing protocols. In case the same prefix is received from more than one neighbor (with distinct routes/paths), many BGP attributes are considered in selecting the best path for that prefix, as documented here.
In the following sections, we will discuss how we can tune some of these attributes to influence BGP path selection process.
BGP Topology
For this tutorial, we will consider the following topology.
Rotuer-A exchanges prefixes with two eBGP neighbors, Router-B and Router-C. Router-D also has eBGP peering with Router-B and Router-C, and exchange prefixes with them. For traffic between Router-A and Router-D, we will consider the following requirements.
- We can modify the configuration of Router-A only, and none of the other routers is under our control.
- For outgoing traffic towards Router-D, Router-A should prefer the path through Router-C. In case this path is unavailable, the path through Router-B will be used.
- For incoming traffic from Router-D, Router-A wants to load balance the traffic between both paths. In case one path fails, all traffic will be carried by the other link.
To keep this tutorial simple, we will not be going into the details of BGP configuration. I am providing the summary of the configuration for reference.
Influencing Outgoing Traffic with Local Preference
The route taken by outbound traffic from Router-A will depend on the prefixes it receives from Router-B and Router-C. While we assume that we are allowed to configure Router-A only, we need to have Router-D advertise prefixes to Router-A for the purpose of demonstration. We will start by configuring Router-D to advertise its own prefixes.
router-d# conf t
router-d(config)# router bgp 400
router-d(config-router)# network 172.16.1.0 mask 255.255.255.0
router-d(config)# router bgp 400
router-d(config-router)# network 172.16.1.0 mask 255.255.255.0
Please note that AS-200 and AS-300 are transit networks. Since there is no active prefix filter defined, these networks will forward all prefixes that they learn to their neighbors.
Now from Router-A's perspective, it receives a prefix 172.16.1.0/24 via both neighbors AS 200 and AS 300. The *> in the output indicates that the preferred path, which is through AS 200, Router-B.
Local preference is a BGP attribute that can be used to influence outbound traffic path. It is also one of the first attributes that is checked during path selection. By design the route with the highest local preference value is the most preferred route. The default local preference is 100.
Be aware that local preference is local to each Autonomous System. That is, local preference values are shared only among routers in the same AS, and never exposed to other neighboring Autonomous Systems.
Now we will increase local preference to 200 for the routes received from Router-C. We will create a route-map in Router-A and use it to modify local preference.
router-a# conf t
router-a(config)# route-map SET-LP permit 10
router-a(config-route-map)# set local-preference 200
router-a(config-route-map)# exit
router-a(config)# route-map SET-LP permit 10
router-a(config-route-map)# set local-preference 200
router-a(config-route-map)# exit
router-a(config)# router bgp 100
router-a(config-router)# neighbor 10.10.13.3 route-map SET-LP in
router-a(config-router)# neighbor 10.10.13.3 route-map SET-LP in
The above commands create a route-map named 'SET-LP'. The sequence 10 of the route-map is a permit statement. As there is no specific 'match' clause, the statement will match all prefixes. The 'set' clause will set the local prefix of all prefixes to 200, which is higher than the default value. We then call this route-map within BGP configuration and apply it in the inbound direction for neighbor 10.10.13.3, Router-C.
Let's verify that the changes have taken effect.
We can interpret the above output as follows.
- The path through Router-C (AS 300) is the preferred path due to higher local preference value.
- The route through Router-B (AS 200) is still being learnt, has the default local preference of 100.
- If, for some reason, Router-C goes down, the path through Route-B will be used as a backup.
This confirms that we have successfully configured outbound traffic policy to match the requirement. traceroute probing should confirm the same.
Note: If your ping/traceroute is not working, make sure that you have enabled packet forwarding in all four routers.
Load Balancing Incoming Traffic with Selective Prefix Advertisements
As far as inbound traffic is concerned, of course we cannot directly manipulate remote routers outside the local AS to influence inbound traffic sent by them. Instead, incoming traffic to an AS can be indirectly influenced by the prefixes that the AS advertise to the world. Remember that the routing tables of remote routers are populated with the prefix advertisements they receive. Thus by selectivey advertising prefixes from our local Router-A, we can influence he routing decision of the neighboring Router-D.
One key factor during route selection in any routing protocol (RIP, OSPF, BGP, IS-IS) is the prefix length. The route with the longest prefix is always the best route, regardless of any protocol-specific administrative distance, attribute, or metric. For example, a prefix with /27 mask is always preferred over /24 mask as it has a longer prefix length.
We will utilize this characteristic of route selection to load balance Router-A's incoming traffic through Router-B and Router-C. Let us look at the prefix that AS 100 owns, and see how we can break it up.
Actual Prefix | Prefix Broken Down | |
/22 | /23 | /24 |
192.168.0.0/22 | 192.168.0.0/23 | 192.168.0.0/24 |
192.168.1.0/24 | ||
192.168.2.0/23 | 192.168.2.0/24 | |
192.168.3.0/24 |
In a lab environment, you can use any prefix length that you want including /32. However, in production environments like publicly routable prefixes, the maximum length of prefix that is allowed is up to /24. For this simulation, we will advertise the /24 and /22 prefixes using the following policy.
- Advertise first two /24 to AS 200
- Advertise the other two /24 to AS 300
- Advertise entire /22 to both AS 200 and AS 300
1. Load Balancing and Fall Back Selection
The following is the prefix selection process on Router-A, which leads to load balancing its incoming traffic.
- The /24 prefixes are the most specific routes as they have the maximum subnet mask length. So the preferred path to the first two /24 prefixes would be through AS 200, and for the latter two /24s it would be through AS 300.
- The /24 prefixes are part of the entire /22 prefix. If, for some reason, Router-D does not receive /24 advertisements from either neighbor, it will remove the route from its routing table. In that case, the only available reference to that particular /24 would be through /22. For example, if Router-D stops receiving the prefix 192.168.3.0/24, the route will be removed from its routing table. If the router has some traffic for this network, the closest available match is 192.168.0.0/22, which it is receiving from both neighbors. So traffic can still be routed to the destination network.
2. Creating Prefix Lists
router-a(config)# ip prefix-list AS200_PRFX_OUT deny 192.168.2.0/23
router-a(config)# ip prefix-list AS200_PRFX_OUT deny 192.168.2.0/24
router-a(config)# ip prefix-list AS200_PRFX_OUT deny 192.168.3.0/24
router-a(config)# ip prefix-list AS200_PRFX_OUT permit 192.168.0.0/22 le 24
router-a(config)# ip prefix-list AS200_PRFX_OUT deny 192.168.2.0/24
router-a(config)# ip prefix-list AS200_PRFX_OUT deny 192.168.3.0/24
router-a(config)# ip prefix-list AS200_PRFX_OUT permit 192.168.0.0/22 le 24
The above commands will create a prefix-list called AS200_PRFX_OUT that will deny the specific /23 and /24 prefixes, while allowing all other prefixes within the 192.168.0.0/22 subnet as long as the prefix length is up to /24. We will create a similar prefix-list for the other /24 prefixes.
router-a(config)# ip prefix-list AS300_PRFX_OUT deny 192.168.0.0/23
router-a(config)# ip prefix-list AS300_PRFX_OUT deny 192.168.0.0/24
router-a(config)# ip prefix-list AS300_PRFX_OUT deny 192.168.1.0/24
router-a(config)# ip prefix-list AS300_PRFX_OUT permit 192.168.0.0/22 le 24
router-a(config)# ip prefix-list AS300_PRFX_OUT deny 192.168.0.0/24
router-a(config)# ip prefix-list AS300_PRFX_OUT deny 192.168.1.0/24
router-a(config)# ip prefix-list AS300_PRFX_OUT permit 192.168.0.0/22 le 24
3. Creating Route-Maps
We will call upon the prefix-lists within route- maps and apply them in the BGP configuration.
router-a(config)# route-map AS200_RMAP_OUT permit 10
router-a(config-route-map)# match ip address prefix-list AS200_PRFX_OUT
router-a(config-route-map)# exit
router-a(config-route-map)# match ip address prefix-list AS200_PRFX_OUT
router-a(config-route-map)# exit
router-a(config)# route-map AS300_RMAP_OUT permit 10
router-a(config-route-map)# match ip address prefix-list AS300_PRFX_OUT
router-a(config-route-map)# exit
router-a(config-route-map)# match ip address prefix-list AS300_PRFX_OUT
router-a(config-route-map)# exit
The above commands create two route-maps that allow prefixes that are matched by the prefix-lists that we created earlier.
router-a(config)# router bgp 100
router-a(config-router)# neighbor 10.10.12.2 route-map AS200_RMAP_OUT out
router-a(config-router)# neighbor 10.10.13.3 route-map AS300_RMAP_OUT out
router-a(config-router)# neighbor 10.10.12.2 route-map AS200_RMAP_OUT out
router-a(config-router)# neighbor 10.10.13.3 route-map AS300_RMAP_OUT out
In the above BGP configuration, we specify that the outbound prefixes advertised towards the neighbors in AS 200 and AS 300 must be filtered through the route-maps that we have just created.
4. Advertising the Prefixes
Now we will advertise the prefixes within BGP configuration.
router-a(config-router)# router bgp 100
router-a(config-router)# network 192.168.0.0 mask 255.255.255.0
router-a(config-router)# network 192.168.1.0 mask 255.255.255.0
router-a(config-router)# network 192.168.2.0 mask 255.255.255.0
router-a(config-router)# network 192.168.3.0 mask 255.255.255.0
router-a(config-router)# network 192.168.0.0 mask 255.255.252.0
router-a(config-router)# network 192.168.0.0 mask 255.255.255.0
router-a(config-router)# network 192.168.1.0 mask 255.255.255.0
router-a(config-router)# network 192.168.2.0 mask 255.255.255.0
router-a(config-router)# network 192.168.3.0 mask 255.255.255.0
router-a(config-router)# network 192.168.0.0 mask 255.255.252.0
5. Verifying the Advertisements
We will verify whether the prefixes are advertised as well as received properly by using the following commands.
For advertised routes:
# show ip bgp <neighbor-IP-address> <advertised-routes>
For received routes:
# show ip bgp <neighbor-IP-address> routes
# show ip bgp
# show ip bgp
The following screenshot confirms that the routes are being advertised and received properly.
6. Testing BGP Fallback
To test whether fallback mechanism works, we will shut down the BGP peering within Route-A and Router-C.
router-a(config)# router bgp 100
router-a(config-router)# neighbor 10.10.13.3 shutdown
router-a(config-router)# neighbor 10.10.13.3 shutdown
As we can see, the route /22 is still being learnt through AS 200. We can use traceroute to verify that the traffic is taking a backup path.
Note: If your ping/traceroute is not working, make sure you have enabled packet forwarding in all four routers.
7. Summary Configuration
For your reference, here is the final configuration of all four routers.
Router-A:
Router-B:
Router-C:
Router-D:
Conclusion
To sum up, we have demonstrated some techniques of BGP traffic engineering to influence inbound and outbound traffic. If we know how we want to route traffic or prepare backup routes for redundancies, there are a lot of options to make it work using BGP, e.g., weight, local preference, AS-path prepend, communities, MED, etc. Traffic engineering can be done using other protocols as well. Remember that the core of proper traffic engineering is planning. At the end of the day, it is planning that is the most important phase. Executing the plan (as demonstrated in this tutorial) is what comes next.
Hope this helps.
Subscribe to Xmodulo
Do you want to receive Linux FAQs, detailed tutorials and tips published at Xmodulo? Enter your email address below, and we will deliver our Linux posts straight to your email box, for free. Delivery powered by Google Feedburner.
Support Xmodulo
Did you find this tutorial helpful? Then please be generous and support Xmodulo!
The following two tabs change content below.Sarmed Rahman is an IT professional based in Australia. He writes tutorial articles on technology every now and then from a belief that knowledge grows through sharing. During his free time, he loves gaming and spending time with his friends.