Lab 13 - Best path selection - Origin

The BGP Best path selection algorithm for BGP looks at several path attributes and evaluates them in the following order of preference:


1. Highest Weight
2. Highest Local preference
3. Locally originated
4. Shortest AS_Path
5. Origin; prefer IGP, before EGP, before Incomplete
6. Lowest MED
7. eBGP paths over iBGP paths
8. Lowest IGP metric to the next hop
9. For eBGP prefixes prefer first received route
10. Lowest router ID
11. Shortest cluster list length
12. Lowest neighbor address


Today's lab will focus on the Origin attribute and how to use it for traffic engineering purposes.


Tasks:
-Establish eBGP peering between R1, R2, R3, and R4
-Establish iBGP peering between R3 and R2.
-Advertise the loopbacks on R1 and R4 into BGP
-Ensure traffic originating from AS 10 destined for AS 40 enters
AS 20 via R3
-You can only use the Origin attribute to accomplish this.


Topology







GNS3 files: Link




Solution


Let's begin by establishing our BGP peering as required by the lab tasks.


R1(config)#router bgp 10
R1(config-router)#neighbor 192.168.12.2 remote-as 20
R1(config-router)#neighbor 192.168.13.3 remote-as 20


R2(config)#router bgp 20
R2(config-router)#neighbor 192.168.12.1 remote-as 10
R2(config-router)#neighbor 192.168.23.3 remote-as 20
R2(config-router)#neighbor 192.168.24.4 remote-as 30


R3(config)#router bgp 20
R3(config-router)#neighbor 192.168.13.1 remote-as 10
R3(config-router)#neighbor 192.168.34.4 remote-as 30


R4(config)#router bgp 30
R4(config-router)#neighbor 192.168.24.2 remote-as 20
R4(config-router)#neighbor 192.168.34.3 remote-as 20


R1(config-router)#network 1.1.1.0 mask 255.255.255.0


R4(config-router)#network 4.4.4.0 mask 255.255.255.0


Next we want to ensure traffic coming into our AS 20 from AS 10 does so through R3. We must do this using the Origin attribute. The origin attribute is a well-known mandatory as-path attribute. It consist of three possible values listed in the order of preference.


• iGP
• eGP
• Incomplete


Origin is 5th in the line of attributes evaluated by the best path algorithm. So in order for the origin attribute to influence routing decisions weight, local preference, local origination, and as-path values must be equal. As it turns out this is the case with the prefixes we need to influence. So we can easily modify the origin attribute using a route-map and apply it outbound on a neighbor statement. Since the current origin values are iGP, the highest value, we want to lower the value of the path we do not want traffic to use. We do this using a route-map and apply it outbound to the neighbor statement of the path we want to influence.


R2(config)#route-map CHANGE_ORIGIN permit
R2(config-route-map)#set origin incomplete
R2(config-route-map)#exit


R2(config)#router bgp 20
R2(config-router)#neighbor 192.168.12.1 route-map CHANGE_ORIGIN out


Now let's compare our BGP RIB's before and after applying our route map to verify our solution.


R1#sh ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.0/24       0.0.0.0                  0         32768 i
 *   4.4.4.0/24       192.168.13.3                           0 20 30 i
 *>                   192.168.12.2                           0 20 30 i


R1#clear ip bgp * soft


R1#sh ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.0/24       0.0.0.0                  0         32768 i
 *>  4.4.4.0/24       192.168.13.3                           0 20 30 i
 *                    192.168.12.2                           0 20 30 ?


A quick trace route to confirm traffic is indeed flowing how we want it.


R1#traceroute 4.4.4.4 source loopback 0
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.13.3 24 msec 44 msec 20 msec
  2 192.168.34.4 40 msec *  84 msec


That’s it! A rather simple solution but this is a simple scenario.




Souces:


http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

Lab 1 - OSPF and Broadcast Media

Our first lab delving into the OSPF world of the CCIE lab exam will focus on some fundamentals related to how OSPF works over broadcast media as well as introduce some basic concepts and common problems associated with design issues related to OSPF with some topologies.

Tasks:
-Using process ID 100 for the following two tasks
1-Configure OSPF area 13 on R1 and R3 without using the OSPF network command
2-Configure OSPF area 34 and area 24 on R3, R4, and R2 using the network command
only, using a seperate network command for each area without any overlap
3-Note any issues related to the current configuration
4-configure fa 0/0 on R1, R2, and R3 in area 0
5-Note any changes to the routing table

Topology

GNS3 Files: Link

Solution

To begin we should establish our peering per the tasks defined by the lab. The tasks ask us to establish peering with specific neighbors using different peering configuration methods. Both methods have the same result and have no material difference in terms of how OSPF establishes the peering.

It's important to note that unlike RIP the network statement as well as the interface command to enable OSPF only enable the process on the interfaces associated with the commands. So with the network statement any interface that has an IP address within the range of the network command would send and receive OSPF hello's. This is also true with the interface command IP OSPF AS Area Area_number. Both commands have the same result but the network command can apply to multiple interfaces. The interface command would apply only to the interface on which it is entered.

Begin configure tasks 1 and 2:

R1(config)#int s1/0

R1(config-if)#ip ospf 100 area 13

R2(config)#router ospf 100

R2(config-router)#network 192.168.24.0 0.0.0.255 area 24

R3(config)#int s1/0

R3(config-if)#ip ospf 100 area 13

R3(config-if)#int s1/1

R3(config-if)#ip ospf 100 area 34

R4(config-if)#router ospf 100

R4(config-router)#network 192.168.34.0 0.0.0.255 area 34

R4(config-router)#network 192.168.24.0 0.0.0.255 area 24

At this point the lab asks us to note any issues with the configuration, so let's take a look.

No summary LSAs:

R1#sh ip ospf database

            OSPF Router with ID (199.198.197.196) (Process ID 100)

                Router Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum Link count

199.198.197.196 199.198.197.196 1347        0x80000001 0x0086C3 1

R1#sh ip route | b Gateway

Gateway of last resort is not set

      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        1.1.1.0/24 is directly connected, Loopback0

L        1.1.1.1/32 is directly connected, Loopback0

      192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.13.0/24 is directly connected, Serial1/0

L        192.168.13.1/32 is directly connected, Serial1/0

      192.168.123.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.123.0/24 is directly connected, FastEthernet0/0

L        192.168.123.1/32 is directly connected, FastEthernet0/0

      199.198.197.0/24 is variably subnetted, 2 subnets, 2 masks

C        199.198.197.0/24 is directly connected, Loopback99

L        199.198.197.196/32 is directly connected, Loopback99

R2#sh ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 100)

                Router Link States (Area 24)

Link ID         ADV Router      Age         Seq#       Checksum Link count

2.2.2.2         2.2.2.2         530         0x80000002 0x0062B6 1

192.168.34.4    192.168.34.4    535         0x80000002 0x00B255 1

                Net Link States (Area 24)

Link ID         ADV Router      Age         Seq#       Checksum

192.168.24.4    192.168.34.4    535         0x80000001 0x00F399

R2#sh ip route | b Gateway

Gateway of last resort is not set

      2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        2.2.2.0/24 is directly connected, Loopback0

L        2.2.2.2/32 is directly connected, Loopback0

      192.168.24.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.24.0/24 is directly connected, FastEthernet0/1

L        192.168.24.2/32 is directly connected, FastEthernet0/1

      192.168.123.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.123.0/24 is directly connected, FastEthernet0/0

L        192.168.123.2/32 is directly connected, FastEthernet0/0

R3#sh ip ospf database

            OSPF Router with ID (199.198.197.196) (Process ID 100)

                Router Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum Link count

199.198.197.196 199.198.197.196 168         0x80000001 0x0086C3 1

                Router Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum Link count

199.198.197.196 199.198.197.196 168         0x80000001 0x0044F0 1

R3#

R3#sh ip route | b Gateway

Gateway of last resort is not set

      3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        3.3.3.0/24 is directly connected, Loopback0

L        3.3.3.3/32 is directly connected, Loopback0

      192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.13.0/24 is directly connected, Serial1/0

L        192.168.13.3/32 is directly connected, Serial1/0

      192.168.34.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.34.0/24 is directly connected, Serial1/1

L        192.168.34.3/32 is directly connected, Serial1/1

      192.168.123.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.123.0/24 is directly connected, FastEthernet0/0

L        192.168.123.3/32 is directly connected, FastEthernet0/0

R4#sh ip ospf database

            OSPF Router with ID (199.198.197.196) (Process ID 100)

                Router Link States (Area 24)

Link ID         ADV Router      Age         Seq#       Checksum Link count

2.2.2.2         2.2.2.2         101         0x80000002 0x0062B6 1

199.198.197.196 199.198.197.196 100         0x80000002 0x0030C4 1

                Net Link States (Area 24)

Link ID         ADV Router      Age         Seq#       Checksum

192.168.24.4    199.198.197.196 100         0x80000001 0x00304A

                Router Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum Link count

199.198.197.196 199.198.197.196 145         0x80000001 0x0044F0 1

R4#sh ip route | b Gateway

Gateway of last resort is not set

      192.168.24.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.24.0/24 is directly connected, FastEthernet0/0

L        192.168.24.4/32 is directly connected, FastEthernet0/0

      192.168.34.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.34.0/24 is directly connected, Serial1/0

L        192.168.34.4/32 is directly connected, Serial1/0

      199.198.197.0/24 is variably subnetted, 2 subnets, 2 masks

C        199.198.197.0/24 is directly connected, Loopback99

L        199.198.197.196/32 is directly connected, Loopback99

So first thing to note is the lack of any summary LSA's on any of the routers. There are two kinds of summary LSA's type 3 and type 4. Type 3 Summary LSA's are a list of all type 1 & 2 LSA's for a given area sent by an ABR to an adjacent area. In short type 3 LSA's provide a complete list of networks outside a given area. Type 3 LSA's are sent between the backbone area and adjacent areas. Type 4 LSA's are generated by ABR for an area with an ASBR and provide path information to build a shortest path tree to an ASBR.

Since inter-area LSA exchange must be done through the backbone area none of the non-backbone areas have received any summary LSA leaving them with an incomplete few of the network.

The second and a little more obvious issue is the following error messages on R1 and R3.

Duplicate Router ID issue:

%OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 199.198.197.196 from 192.168.13.1 on interface Serial1/0

%OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 199.198.197.196 from 192.168.13.3 on interface Serial1/0

The message indicates a potential configuration or design issue. Specifically the error message indicates duplicate router ID's on the devices where the messages are displayed. The problem creates problems due to the fact that LSA's origination is based on router-id. The routers see duplicate LSA ID's causing continual recalculation of SPF indicated by the log message.

The solution to this problem is simple either change the loopback address IP on one router and then clear the OSPF process or use the router-id command to specify a new router-id on one of the devices. Each option will cause the router to recalculate SPF and flood updated LSA's out.

So I will use the router-id option on both R1 and R3. Issueing this command brings the neighbor state down momentarily to allow SPF recalculation.

R1(config)#router ospf 100

R1(config-router)#router-id 1.1.1.1

*Aug  4 19:16:02.799: %OSPF-5-ADJCHG: Process 100, Nbr 199.198.197.196 on Serial1/0 from LOADING to FULL, Loading Done

R3(config)#router ospf 100

R3(config-router)#router-id 3.3.3.3

% OSPF: Reload or use "clear ip ospf process" command, for this to take effect

The OSPF process must be restarted to use the new router-id.

Finally we configure our backbone interfaces.

R1(config)#int fa 0/0

R1(config-if)#ip ospf 100 area 0

R1(config)#int fa 0/0

R1(config-if)#ip ospf 100 area 0

R1(config)#int fa 0/0

R1(config-if)#ip ospf 100 area 0

And with that configuration in place we see all our LSA's.

R1#sh ip ospf database

            OSPF Router with ID (1.1.1.1) (Process ID 100)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.1.1.1         1.1.1.1         19          0x80000002 0x002437 1

2.2.2.2         2.2.2.2         20          0x80000002 0x00E56C 1

3.3.3.3         3.3.3.3         20          0x80000002 0x00A7A1 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum

192.168.123.3   3.3.3.3         20          0x80000001 0x004CDD

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum

192.168.13.0    1.1.1.1         99          0x80000001 0x00ACD5

192.168.13.0    3.3.3.3         60          0x80000001 0x00700A

192.168.24.0    2.2.2.2         74          0x80000001 0x009C16

192.168.34.0    3.3.3.3         60          0x80000001 0x0088DC

                Router Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.1.1.1         1.1.1.1         99          0x80000003 0x00D4CA 2

3.3.3.3         3.3.3.3         60          0x80000002 0x001680 2

                Summary Net Link States (Area 13)

Link ID         ADV Router      Age         Seq#       Checksum

192.168.24.0    1.1.1.1         9           0x80000001 0x00C4F0

192.168.24.0    3.3.3.3         15          0x80000001 0x008825

192.168.34.0    1.1.1.1         14          0x80000001 0x00CE9D

192.168.34.0    3.3.3.3         60          0x80000001 0x0088DC

192.168.123.0   1.1.1.1         89          0x80000001 0x0075DD

192.168.123.0   3.3.3.3         50          0x80000001 0x003912

Sources

http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/23862-duplicate-router-id-ospf.html

https://supportforums.cisco.com/document/133976/reading-and-understanding-ospf-database

Lab 12 - Bestpath Selection - ASPATH Prepend

Today we will look at a more practical method to control traffic as it enters an autonomous system called AS-Path prepending. This is the third attribute in the list of attributes evaluated during the best path selection process and is more commonly used in production environment to control how traffic enters a network.

Tasks to complete

Tasks to complete this lab:

-Configure eBGP peering between R1 and ISP1

-Configure eBGP peering between R2 and ISP2

-Configure iBGP peering between R1 and R2

-advertise the loopback addresses on R1 and R2 such that traffic

 enters AS 65101 via R2's fa 0/1 interface for R1's prefixes

-Advertise the loopback addresses on R2 such that traffic originating from ISP2 enters AS 65101 via R2's S1/0 interface for R2 loopback address and via R1s s1/0 interface for R1's loopback addresses

Topology

GNS3 files: Link

Solution

So as I always do with these labs, I begin by setting up the basics and in this case that would be our peering configuration.

R1(config)#router bgp 65101

R1(config-router)#neighbor 192.168.12.2 remote-as 65101

R1(config-router)# neighbor 192.168.13.11 remote-as 65102

R2(config)#router bgp 65101

R2(config-router)#neighbor 192.168.12.1 remote-as 65101

R2(config-router)#neighbor 192.168.23.11 remote-as 65102

R2(config-router)#neighbor 192.168.24.22 remote-as 65103

And let's advertise our loopbacks to our ISP's

R1(config)#router bgp 65101

R1(config-router)#network 10.10.0.0 mask 255.255.255.0

R1(config-router)#network 10.10.1.0 mask 255.255.255.0

R1(config-router)#network 10.10.2.0 mask 255.255.255.0

R1(config-router)#network 10.10.3.0 mask 255.255.255.0

R2(config)#router bgp 65101

R2(config-router)#network 10.10.4.0 mask 255.255.255.0

R2(config-router)#network 10.10.5.0 mask 255.255.255.0

R2(config-router)#network 10.10.6.0 mask 255.255.255.0

R2(config-router)#network 10.10.7.0 mask 255.255.255.0

Now let's see how things look from our ISP's perspective though normally you wouldn't really be able to do this.

ISP1#sh ip bgp | b Network

   Network          Next Hop            Metric LocPrf Weight Path

*  10.10.0.0/24     99.1.1.22                              0 65103 65101 i

*                          192.168.23.2                           0 65101 i

*>                    192.168.13.1             0             0 65101 i

*  10.10.1.0/24     99.1.1.22                              0 65103 65101 i

*                   192.168.23.2                           0 65101 i

*>                  192.168.13.1             0             0 65101 i

*  10.10.2.0/24     99.1.1.22                              0 65103 65101 i

*                   192.168.13.1             0             0 65101 i

*>                  192.168.23.2                           0 65101 i

*  10.10.3.0/24     99.1.1.22                              0 65103 65101 i

*                   192.168.13.1             0             0 65101 i

*>                  192.168.23.2                           0 65101 i

*  10.10.4.0/24     99.1.1.22                              0 65103 65101 i

*                   192.168.13.1                           0 65101 i

*>                  192.168.23.2             0             0 65101 i

*  10.10.5.0/24     192.168.13.1                           0 65101 i

*                   99.1.1.22                              0 65103 65101 i

*>                  192.168.23.2             0             0 65101 i

*  10.10.6.0/24     99.1.1.22                              0 65103 65101 i

*                   192.168.13.1                           0 65101 i

*>                  192.168.23.2             0             0 65101 i

*  10.10.7.0/24     99.1.1.22                              0 65103 65101 i

   Network          Next Hop            Metric LocPrf Weight Path

*                   192.168.13.1                           0 65101 i

*>                  192.168.23.2             0             0 65101 i

ISP2#sh ip bgp | b Network

   Network          Next Hop            Metric LocPrf Weight Path

*> 10.10.0.0/24     192.168.24.2                           0 65101 i

*                   99.1.1.11                              0 65102 65101 i

*  10.10.1.0/24     99.1.1.11                              0 65102 65101 i

*>                  192.168.24.2                           0 65101 i

*  10.10.2.0/24     99.1.1.11                              0 65102 65101 i

*>                  192.168.24.2                           0 65101 i

*  10.10.3.0/24     99.1.1.11                              0 65102 65101 i

*>                  192.168.24.2                           0 65101 i

*  10.10.4.0/24     99.1.1.11                              0 65102 65101 i

*>                  192.168.24.2             0             0 65101 i

*  10.10.5.0/24     99.1.1.11                              0 65102 65101 i

*>                  192.168.24.2             0             0 65101 i

*  10.10.6.0/24     99.1.1.11                              0 65102 65101 i

*>                  192.168.24.2             0             0 65101 i

*  10.10.7.0/24     99.1.1.11                              0 65102 65101 i

*>                  192.168.24.2             0             0 65101 i

OK, things look as if they have been advertise correctly. But we have some specific traffic engineering requirements that the lab has specified.

First we need to have any traffic originating in AS 65102 enter AS 65101 via R2's fa0/1 interface. Since BGP is a vector based protocol and a longer AS prefix is less desirable adding additional AS to the AS-Path set would make other paths more desirable. So let's begin by prepending a few more AS 65101's to the advertisement going out fa0/1. That way that vector will be less desirable.

R1(config)#route-map AS_PREPEND permit

R1(config-route-map)#set as-path prepend 65101 65101 65101

R1(config-route-map)#exit

R1(config)#router bgp 65101

R1(config-router)#neighbor 192.168.13.11 route-map AS_PREPEND out

R2(config)#route-map AS_PREPEND permit

R2(config-route-map)#set as-path prepend 65101 65101 65101

R2(config-route-map)#exit

R2(config)#router bgp 65101

R2(config-router)#neighbor 192.168.24.11 route-map AS_PREPEND out

In this solution I've elected to prepend all outbound advertised routes to the selected neighbor but it would be also possible to use an ACL, prefix-list, or as-path access list to filter which prefixes to prepend if that was required.

So let's look at the results…

ISP1#sh ip bgp | b Network

   Network          Next Hop            Metric LocPrf Weight Path

*> 10.10.0.0/24     192.168.23.2                           0 65101 i

*                   192.168.13.1             0             0 65101 65101 65101 65101 i

*> 10.10.1.0/24     192.168.23.2                           0 65101 i

*                   192.168.13.1             0             0 65101 65101 65101 65101 i

*  10.10.2.0/24     192.168.13.1             0             0 65101 65101 65101 65101 i

*>                  192.168.23.2                           0 65101 i

*  10.10.3.0/24     192.168.13.1             0             0 65101 65101 65101 65101 i

*>                  192.168.23.2                           0 65101 i

*  10.10.4.0/24     192.168.13.1                           0 65101 65101 65101 65101 i

*>                  192.168.23.2             0             0 65101 i

*  10.10.5.0/24     192.168.13.1                           0 65101 65101 65101 65101 i

*>                  192.168.23.2             0             0 65101 i

*  10.10.6.0/24     192.168.13.1                           0 65101 65101 65101 65101 i

*>                  192.168.23.2             0             0 65101 i

*  10.10.7.0/24     192.168.13.1                           0 65101 65101 65101 65101 i

*>                  192.168.23.2             0             0 65101 i

ISP2#sh ip bgp | b Network

   Network          Next Hop            Metric LocPrf Weight Path

*  10.10.0.0/24     192.168.24.2                           0 65101 65101 65101 65101 i

*>                  99.1.1.11                              0 65102 65101 i

*> 10.10.1.0/24     99.1.1.11                              0 65102 65101 i

*                   192.168.24.2                           0 65101 65101 65101 65101 i

*> 10.10.2.0/24     99.1.1.11                              0 65102 65101 i

*                   192.168.24.2                           0 65101 65101 65101 65101 i

*> 10.10.3.0/24     99.1.1.11                              0 65102 65101 i

*                   192.168.24.2                           0 65101 65101 65101 65101 i

*> 10.10.4.0/24     99.1.1.11                              0 65102 65101 i

*                   192.168.24.2             0             0 65101 65101 65101 65101 i

*> 10.10.5.0/24     99.1.1.11                              0 65102 65101 i

*                   192.168.24.2             0             0 65101 65101 65101 65101 i

*> 10.10.6.0/24     99.1.1.11                              0 65102 65101 i

*                   192.168.24.2             0             0 65101 65101 65101 65101 i

*> 10.10.7.0/24     99.1.1.11                              0 65102 65101 i

*                   192.168.24.2             0             0 65101 65101 65101 65101 i

That looks correct, but let's confirm things

ISP1#traceroute 10.10.0.1 source loopback 10

Type escape sequence to abort.

Tracing the route to 10.10.0.1

  1 192.168.23.2 20 msec 24 msec 28 msec

  2 192.168.12.1 24 msec *  60 msec

ISP1#traceroute 10.10.4.1 source loopback 10

Type escape sequence to abort.

Tracing the route to 10.10.4.1

  1 192.168.23.2 20 msec *  44 msec

ISP2#traceroute 10.10.0.1 source loopback 10

Type escape sequence to abort.

Tracing the route to 10.10.0.1

  1 99.1.1.11 20 msec 24 msec 36 msec

  2 192.168.23.2 24 msec 32 msec 36 msec

  3 192.168.12.1 88 msec *  60 msec

ISP2#traceroute 10.10.4.1 source loopback 10

Type escape sequence to abort.

Tracing the route to 10.10.4.1

  1 99.1.1.11 16 msec 32 msec 24 msec

  2 192.168.23.2 24 msec *  56 msec

We are all done…

I welcome anyone's constructive input or thoughts on the above lab and its solution. Simply comment below... 

Sources:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

Lab 11 - Bestpath Selection - Local Preference

This lab focuses on the local preference as-path attribute. This metric is second in line when evaluating best paths by BGP. Second to the cisco proprietary metric WEIGHT, the local preference is carried along with iBGP updates within an AS and is used to indicate to an AS a preferred exit for a particular prefix. Often times this is used in multi-ISP topologies as a traffic engineering tool to steer traffic towards a particular ISP.

Concepts covered:

-eBGP and iBGP peering

-BGP local-preference

-Route-maps and As-path access lists

-Regular Expressions

Tasks to complete lab:

-Establish eBGP peering between R1-ISP3 and R2-ISP2

-Establish a full mesh iBGP peering between R1,R2, and R3

-Configure traffic flow within AS 65123 such that packets destined for any

AS 10 prefixes prefer to exit using ISP2 when sourced from R3's loopback 0 address

-All other traffic should exit based on advertised path preference from the ISP

constraints:

-Do not modify any IGP settings

-Do not use static routes

-Only AS10 prefixes should be modified to prefer exiting via AS20.

Topology

GNS3 files: Link

Solution

Begin by establishing BGP peering per the task list. We should also include the next-hop-self command on the edge BGP speakers in our iBGP domain so that prefixes advertised into our iBGP has reachable next hops.

R1(config)#router bgp 65123

R1(config-router)#neighbor 192.168.31.3 remote-as 30

R1(config-router)#neighbor 192.168.123.2 remote-as 65123

R1(config-router)#neighbor 192.168.123.3 remote-as 65123

R1(config-router)#neighbor 192.168.123.2 next-hop-self

R1(config-router)#neighbor 192.168.123.3 next-hop-self

R2(config)#router bgp 65123

R2(config-router)#neighbor 192.168.22.22 remote-as 20

R2(config-router)#neighbor 192.168.123.1 remote-as 65123

R2(config-router)#neighbor 192.168.123.3 remote-as 65123

R2(config-router)#neighbor 192.168.123.1 next-hop-self

R2(config-router)#neighbor 192.168.123.3 next-hop-self

R3(config)#router bgp 65123

R3(config-router)#neighbor 192.168.123.1 remote-as 65123

R3(config-router)#neighbor 192.168.123.2 remote-as 65123

Next we use a route-map to modify the local preference to influence the best path decision for routes existing the 65123 AS. Local Preference is an indication to the AS of a preference to exit the AS. Its is advertised to other iBGP peers and a higher local preference is more prefered.

R2(config)#route-map SET_LOCAL_PREFERENCE permit 10

R2(config-router)#match as-path 1

R2(config-router)#set local-preference 101

R2(config)#route-map SET_LOCAL_PREFERENCE permit 9999

Then we apply our route map inbound to our ISP2 neighbor

R2(config)#router bgp 65123

R2(config-router)#neighbor 192.168.31.33 route-map SET_LOCAL_PREFERENCE in

When you apply the route map inbound and do a soft clearing of the BGP peering you get the following results.

R2(config)#do clear ip bgp * soft

R3#sh ip bgp | be Network

     Network          Next Hop            Metric LocPrf Weight Path

 *>i 172.16.0.0/24    192.168.123.2            0    101      0 20 10 i

 *>i 172.16.1.0/24    192.168.123.2            0    101      0 20 10 i

 *>i 172.16.2.0/24    192.168.123.2            0    101      0 20 10 i

 *>i 172.16.3.0/24    192.168.123.2            0    101      0 20 10 i

 *>i 172.16.4.0/24    192.168.123.2            0    101      0 20 10 i

 *>i 172.16.5.0/24    192.168.123.2            0    101      0 20 10 i

 *>i 172.16.6.0/24    192.168.123.2            0    101      0 20 10 i

 *>i 172.16.7.0/24    192.168.123.2            0    101      0 20 10 i

We have our preferred route and traffic is following the path that we selected.

R3#ping 172.16.2.1 source loopback 0

Pending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds:

Packet sent with a source address of 3.3.3.3

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 52/79/116 ms

R3#traceroute 172.16.2.1 source loopback 0

Type escape sequence to abort.

Tracing the route to 172.16.2.1

VRF info: (vrf in name/id, vrf out name/id)

  1 192.168.123.2 20 msec 32 msec 24 msec

  2 192.168.22.22 60 msec 24 msec 88 msec

  3 192.168.12.1 88 msec *  116 msec

But notice that we have lost our alternative path through ISP3 on R3 in its BGP RIB and FIB tables. This is because R1 is receiving the prefix from R2 with the modified local preference and consequently that path is not the BEST path in R1's BGP RIB anymore. Since BGP only advertises best paths AND iBGP split horizon prevents re-advertisement of iBGP learned routes. R1 does not advertise the new R2 learned prefixes to R2 and R3. The results are to be expected and provide us the solution we wanted which is to force traffic for AS10's prefix out through ISP2.

Note: It should be noted that AS 65123 is technically a transit network for the 172.16.0.0/24 network given the current configuration. Normally you would want to filter things using a similar route filtering method as in this lab and an as-path access list with ^$ regex so that only locally originated routes are advertised to ISP2 and ISP4. But that will be the topic of another lab in the near future.

Sources:

BGP case studies:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html

BGP best path algorithm:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html