Lab 19 - Bestpath Selection - Filter by ASPath length

The BGP maxas-limit command is used to limit the maximum ASPath segments received from a BGP neighbor. This feature can provide protection and filtering opportunities based on the ASPath length. Today's lab will focus on this specific feature and how to use it to filter inbound ASPath segments based on ASpath length.

Concepts tested

• Filter inbound ASPATH segments based on length
• Configuring basic BGP  peering

Topology

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

R1 Configuration

R1(config)#router bgp 65001
R1(config-router)#neighbor 65.1.0.2 remote 65002
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#neighbor 65.1.0.2 activate
R1(config-router-af)#bgp maxas-limit 2

R1 Verification

Once you configure your neighbor statement and the peering comes up you should see the following:

%BGP-5-ADJCHANGE: neighbor 65.1.0.2 Up

R1#sh ip bgp | b Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  160.150.1.0/24   65.1.0.2                 0             0 65002 i
 *>  160.151.1.0/24   65.1.0.2                 0             0 65002 65123 i
 *>  160.152.1.0/24   65.1.0.2                 0             0 65002 65123 65223 i
 *>  160.153.1.0/24   65.1.0.2                 0             0 65002 65123 65223 i

Now based on the ASPATH information above we could filter any prefixes from AS65223 by simply limiting the ASPath length using the command bgp maxas-limit #.

With that command configured and we clear our peering session we should see the following:

R1#clear bgp ipv4 unicast * soft

%BGP-6-ASPATH: Long AS path 65002 65123 65223 received from 65.1.0.2: BGP(0) Prefixes: 160.152.1.0/24 160.153.1.0/24

R1#sh ip bgp | b Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  160.150.1.0/24   65.1.0.2                 0             0 65002 i
 *>  160.151.1.0/24   65.1.0.2                 0             0 65002 65123 i
R1#

Now we only see the prefixes we want to see, and that is it for this lab.

Lab 18 - Bestpath Selection - DMZ Link Bandwidth

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


The feature DMZ link bandwidth in BGP is similar in functionality to EIGRPs unequal load balancing in that it can instruct the routers data plane to load share across unequal paths based on the links bandwidth. Today's lab will focus on a simple implementation of this feature.


Tasks:
-Establish iBGP peering between routers R1, R2, and R5 in AS 100
-Establish iBGP peering between routers R3 and R4 in AS 200
-Establish iBGP peering between R1 and R2 in AS 100 with R3 and R4 in AS 200
-Advertise the loopbacks of R3 and R4 into BGP and ensure that all paths are used
 when existing AS 100 toward AS 200
-Configure BGP such that R1,R2, and R5 learn of the multiple paths toward the AS 200
loopback addresses and use the bandwidth of each path to evaluate how to load
balance traffic across the multiple paths.




Topology







GNS3 files: Link




Solution:


Let's begin by establishing our peering per the labs requirements. Remember to verify your peering is correct before moving on to the next step; sh ip bgp sum…


R1(config)#router bgp 100
R1(config-router)#address-family ipv4
R1(config-router-af)#neighbor 146.1.0.2 remote-as 100
R1(config-router-af)#neighbor 146.1.0.2 next-hop-self
R1(config-router-af)#neighbor 146.1.0.5 remote-as 100
R1(config-router-af)#neighbor 146.1.0.5 next-hop-self
R1(config-router-af)#neighbor 192.168.13.3 remote-as 200
R1(config-router-af)#neighbor 192.168.14.4 remote-as 200


R2(config)#router bgp 100
R2(config-router)#address-family ipv4
R2(config-router-af)#neighbor 146.1.0.1 remote-as 100
R2(config-router-af)#neighbor 146.1.0.1 next-hop-self
R2(config-router-af)#neighbor 146.1.0.5 remote-as 100
R2(config-router-af)#neighbor 146.1.0.5 next-hop-self
R2(config-router-af)#neighbor 192.168.24.4 remote-as 200


R3(config)#router bgp 200
R3(config-router)#address-family ipv4
R3(config-router-af)#neighbor 192.168.13.1 remote-as 100
R3(config-router-af)#neighbor 192.168.34.4 remote-as 200


R4(config-router)#address-family ipv4
R4(config-router-af)#neighbor 192.168.14.1 remote-as 100
R4(config-router-af)#neighbor 192.168.24.2 remote-as 100
R4(config-router-af)#neighbor 192.168.34.3 remote-as 200


R5(config)#router bgp 100
R5(config-router)#address-family ipv4
R5(config-router-af)# neighbor 146.1.0.1 remote-as 100
R5(config-router-af)# neighbor 146.1.0.2 remote-as 100


Next we advertise the loopbacks per the lab requirements.


R3(config-router)#address-family ipv4
R3(config-router-af)#network 3.3.3.3 mask 255.255.255.255


R4(config-router)#address-family ipv4
R4(config-router-af)#network 4.4.4.4 mask 255.255.255.255


Let's verify the networks are being advertised into BGP


R5#sh ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 3.3.3.3/32       146.1.0.1                0    100      0 200 i
 * i                  192.168.24.4             0    100      0 200 i
 *>i 4.4.4.4/32       146.1.0.1                0    100      0 200 i
 * i                  192.168.24.4             0    100      0 200 i


The next and final requirement involves several steps. The task asks us to enable BGP multipath using the bandwidth of each path as the load evaluator to the advertised prefixes. In BGP this feature is called BGP Link bandwidth and is used to advertise the bandwidth of an autonomous system exit link as an extended community and is used in conjunction with BGP multipath configuration. You enable the BGP link bandwidth feature by configuring the dmzlink-bw option on the neighbor command for a directly connected neighbor. When this feature is enabled the bandwidth can be propagated via extended community advertisement to iBGP peers. This feature when enabled along with other BGP multipath features allows unequal bandwidth load balancing.


R1(config-router)#address-family ipv4
R1(config-router-af)#neighbor 146.1.0.2 send-community extended
R1(config-router-af)#neighbor 146.1.0.5 send-community extended
R1(config-router-af)#neighbor 192.168.13.3 dmzlink-bw
R1(config-router-af)#neighbor 192.168.14.4 dmzlink-bw


R2(config-router)#address-family ipv4
R2(config-router-af)#neighbor 146.1.0.1 send-community extended
R2(config-router-af)#neighbor 146.1.0.2 send-community extended
R2(config-router-af)#neighbor 146.1.0.5 send-community extended
R2(config-router-af)#neighbor 192.168.24.4 dmzlink-bw


With these command enabled we see the bandwidth being added as an extended community attribute to each participating prefix but multipath is still not enabled.


R1(config-router-af)#do sh ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 14
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     4          5
  Refresh Epoch 1
  200
    192.168.14.4 from 192.168.14.4 (4.4.4.4)
      Origin IGP, localpref 100, valid, external
      DMZ-Link Bw 96 kbytes
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200
    192.168.13.3 from 192.168.13.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, external, best
      DMZ-Link Bw 64 kbytes
      rx pathid: 0, tx pathid: 0x0




R5(config-router)#do sh ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 18
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  200
    192.168.13.3 (metric 5512192) from 146.1.0.1 (192.168.14.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      DMZ-Link Bw 64 kbytes
      rx pathid: 0, tx pathid: 0x0


To enable multipath two more commands are required. First maximum-paths is needed to enable multipath and sets the maximum number of multiple paths the system will allow. Second is maximum-paths ibgp 4, this command defines how many iBGP routes can been  entered into the IP routing table.


R1(config-router)#address-family ipv4
R1(config-router-af)#maximum-paths 4
R1(config-router-af)#maximum-paths ibgp 4
R1(config-router-af)#bgp dmzlink-bw




R2(config-router)#address-family ipv4
R2(config-router-af)#maximum-paths 4
R2(config-router-af)#maximum-paths ibgp 4
R2(config-router-af)#bgp dmzlink-bw


R5(config)#router bgp 100
R5(config-router)#address-family ipv4
R5(config-router-af)#maximum-paths ibgp 4
R5(config-router-af)#bgp dmzlink-bw


Now we should confirm BGP see the multiple paths and that they have been added to the IP routing table.


R1#sh ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 2
Paths: (2 available, best #2, table default)
Multipath: eBGP iBGP
  Advertised to update-groups:
     6          7
  Refresh Epoch 1
  200
    192.168.14.4 from 192.168.14.4 (4.4.4.4)
      Origin IGP, localpref 100, valid, external, multipath(oldest)
      DMZ-Link Bw 96 kbytes
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200
    192.168.13.3 from 192.168.13.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, external, multipath, best
      DMZ-Link Bw 64 kbytes
      rx pathid: 0, tx pathid: 0x0


Shown below we see that the IP routing table does indeed see two routes to the 3.3.3.3/32 network and load sharing is being done.


R1#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "bgp 100", distance 20, metric 0
  Tag 200, type external
  Last update from 192.168.13.3 00:01:49 ago
  Routing Descriptor Blocks:
    192.168.14.4, from 192.168.14.4, 00:01:49 ago
      Route metric is 0, traffic share count is 8
      AS Hops 1
      Route tag 200
      MPLS label: none
  * 192.168.13.3, from 192.168.13.3, 00:01:49 ago
      Route metric is 0, traffic share count is 5
      AS Hops 1
      Route tag 200
      MPLS label: none


This can be further verified by looking at the CEF table to confirm that traffic is indeed being load shared and what interfaces the packets being forwarded out. The output below shows that for every 8 packets being sent out s1/1, 5 packets are sent out s1/0.


R1#sh ip cef 3.3.3.3 internal
3.3.3.3/32, epoch 0, flags rib only nolabel, rib defined all labels, RIB[B], refcount 5, per-destination sharing
  sources: RIB
  feature space:
   IPRM: 0x00018000
  ifnums:
   Serial1/0(5)
   Serial1/1(6)
  path 68714258, path list 686E5860, share 5/5, type recursive, for IPv4
  recursive via 192.168.13.3[IPv4:Default], fib 686E7468, 1 terminal fib, v4:Default:192.168.13.3/32
    path 687141E0, path list 68716754, share 1/1, type recursive, for IPv4, flags doesnt-source-via, cef-internal
    recursive via 192.168.13.0/24<nh:192.168.13.3>[IPv4:Default], fib 6726EDA4, 1 terminal fib, v4:Default:192.168.13.0/24
      path 677373D4, path list 677371AC, share 1/1, type connected prefix, for IPv4
      connected to Serial1/0, adjacency IP adj out of Serial1/0 672E6F40
  path 687142D0, path list 686E5860, share 8/8, type recursive, for IPv4
  recursive via 192.168.14.4[IPv4:Default], fib 686E74E4, 1 terminal fib, v4:Default:192.168.14.4/32
    path 68714348, path list 686E58AC, share 1/1, type recursive, for IPv4, flags doesnt-source-via, cef-internal
    recursive via 192.168.14.0/24<nh:192.168.14.4>[IPv4:Default], fib 6726EC30, 1 terminal fib, v4:Default:192.168.14.0/24
      path 686E6250, path list 686E5BF0, share 1/1, type connected prefix, for IPv4
      connected to Serial1/1, adjacency IP adj out of Serial1/1 672E6DE0
  output chain:
    loadinfo 6726D058, per-session, 2 choices, flags 0003, 6 locks
    flags: Per-session, for-rx-IPv4
    13 hash buckets
      < 0 > IP adj out of Serial1/0 672E6F40
      < 1 > IP adj out of Serial1/1 672E6DE0
      < 2 > IP adj out of Serial1/0 672E6F40
      < 3 > IP adj out of Serial1/1 672E6DE0
      < 4 > IP adj out of Serial1/0 672E6F40
      < 5 > IP adj out of Serial1/1 672E6DE0
      < 6 > IP adj out of Serial1/0 672E6F40
      < 7 > IP adj out of Serial1/1 672E6DE0
      < 8 > IP adj out of Serial1/0 672E6F40
      < 9 > IP adj out of Serial1/1 672E6DE0
      <10 > IP adj out of Serial1/1 672E6DE0
      <11 > IP adj out of Serial1/1 672E6DE0
      <12 > IP adj out of Serial1/1 672E6DE0
    Subblocks:
     None


R5 receives the bandwidth information via the extended community value advertised from R1 and R2 and updates the IP routing table with the additional iBGP prefix.


R5#sh ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 8
Paths: (2 available, best #2, table default)
Multipath: eBGP iBGP
  Not advertised to any peer
  200
    146.1.0.2 from 146.1.0.2 (192.168.24.2)
      Origin IGP, metric 0, localpref 100, valid, internal, multipath
      DMZ-Link Bw 193 kbytes
  200
    146.1.0.1 from 146.1.0.1 (192.168.14.1)
      Origin IGP, metric 0, localpref 100, valid, internal, multipath, best
      DMZ-Link Bw 160 kbytes


R5#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "bgp 100", distance 200, metric 0
  Tag 200, type internal
  Last update from 146.1.0.1 00:00:33 ago
  Routing Descriptor Blocks:
    146.1.0.2, from 146.1.0.2, 00:00:33 ago
      Route metric is 0, traffic share count is 6
      AS Hops 1
      Route tag 200
      MPLS label: none
  * 146.1.0.1, from 146.1.0.1, 00:00:33 ago
      Route metric is 0, traffic share count is 5
      AS Hops 1
      Route tag 200
      MPLS label: none


Below the CEF table is load balancing traffic at a 6 to 5 packet ratio.


R5#sh ip cef 3.3.3.3 internal
3.3.3.3/32, epoch 0, flags rib only nolabel, rib defined all labels, RIB[B], refcount 5, per-destination sharing
  sources: RIB
  feature space:
   IPRM: 0x00018000
  ifnums:
   GigabitEthernet0/0(4): 146.1.0.1, 146.1.0.2
  path 686D156C, path list 686CFD54, share 4/5, type recursive, for IPv4
  recursive via 146.1.0.1[IPv4:Default], fib 686D2618, 1 terminal fib, v4:Default:146.1.0.1/32
    path 686D165C, path list 686CFDA0, share 1/1, type adjacency prefix, for IPv4
    attached to GigabitEthernet0/0, adjacency IP adj out of GigabitEthernet0/0, addr 146.1.0.1 672E6F80
  path 686D15E4, path list 686CFD54, share 6/6, type recursive, for IPv4
  recursive via 146.1.0.2[IPv4:Default], fib 686D259C, 1 terminal fib, v4:Default:146.1.0.2/32
    path 686D18B4, path list 686CFD08, share 1/1, type adjacency prefix, for IPv4
    attached to GigabitEthernet0/0, adjacency IP adj out of GigabitEthernet0/0, addr 146.1.0.2 672E6E20
  output chain:
    loadinfo 6726D098, per-session, 2 choices, flags 0003, 6 locks
    flags: Per-session, for-rx-IPv4
    11 hash buckets
      < 0 > IP adj out of GigabitEthernet0/0, addr 146.1.0.1 672E6F80
      < 1 > IP adj out of GigabitEthernet0/0, addr 146.1.0.2 672E6E20
      < 2 > IP adj out of GigabitEthernet0/0, addr 146.1.0.1 672E6F80
      < 3 > IP adj out of GigabitEthernet0/0, addr 146.1.0.2 672E6E20
      < 4 > IP adj out of GigabitEthernet0/0, addr 146.1.0.1 672E6F80
      < 5 > IP adj out of GigabitEthernet0/0, addr 146.1.0.2 672E6E20
      < 6 > IP adj out of GigabitEthernet0/0, addr 146.1.0.1 672E6F80
      < 7 > IP adj out of GigabitEthernet0/0, addr 146.1.0.2 672E6E20
      < 8 > IP adj out of GigabitEthernet0/0, addr 146.1.0.1 672E6F80
      < 9 > IP adj out of GigabitEthernet0/0, addr 146.1.0.2 672E6E20
      <10 > IP adj out of GigabitEthernet0/0, addr 146.1.0.2 672E6E20
    Subblocks:
     None


That’s all there is to that.




Sources:


http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsbgplb.html


http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg-link-band.html


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


http://www.cisco.com/c/en/us/td/docs/ios/12_2sx/feature/guide/fsxeibmp.html

Lab 17 - BGP Best path selection - Router ID

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


Topology







GNS3 files: Link




Solution


This lab touches on the next as-path attribute in the best path selecting process which is the router-id. When evaluating equal paths and when all other higher priority attributes are equal the BGP algorithm compares the router-id of the advertising peer and selects the lower router-id as the preferred path. 


In this lab we are initially asked to create loopback interfaces on R2 and R3 with identical IP address to simulate a dual path scenario.


R2(config)#interface loopback 10
R2(config-if)#ip add 192.1.1.1 255.255.255.255


R3(config)#int lo 10
R3(config-if)#ip add 192.1.1.1 255.255.255.255


With the loopback interfaces created we are then asked to establish iBGP peering between R1, R2, and R3.


R1(config)#router bgp 100
R1(config-router)#neighbor 192.168.21.2 remote-as 100
R1(config-router)#neighbor 192.168.13.3 remote-as 100


R2(config)#router bgp 100
R2(config-router)#neighbor 192.168.21.1 remote-as 100
R2(config-router)#neighbor 192.168.23.3 remote-as 100


R3(config)#router bgp 100
R3(config-router)#neighbor 192.168.13.1 remote-as 100
R3(config-router)#neighbor 192.168.23.2 remote-as 100


At this point if you have configure things in the order ask for in the lab you may find yourself faced with the following error message being logged on both R2 and R3.


 %BGP-3-NOTIFICATION: sent to neighbor 192.168.23.3 passive 2/3 (BGP identifier wrong)


In addition you will note that the BGP peering has not been established between these two neighbors.


R2(config-router)#do sh ip bgp sum
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.21.1    4          100       8       9        1    0    0 00:05:02        0
192.168.23.3    4          100       0       0        1    0    0 never    Idle


R3(config-router)#do sh ip bgp sum
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.13.1    4          100       9      10        2    0    0 00:05:07        0
192.168.23.2    4          100       0       0        1    0    0 never    Idle


So what is going on here you might ask. The problem is twofold and based on the order of operation in which you entered your commands. BGP when initially configured will look and assign a router-id if one is not explicitly configured under the BGP router process. It will use loopbacks first and choose the loopback with the highest IP address. In our case we had only the one loopback on R2 and R3 and each configured with the same IP address. This caused the BGP processes on R2 and R3 to choose the same router-id for which is the root cause of our error. Both routers see their own router-id (BGP Identifier) in the exchange BGP open messages. This is not allowed and the peering is not established.


The solution is relatively simple and is also the means by which we solve the final requirement of the lab which Is to ensure R2 is the preferred path to 192.1.1.1/32 from R1. Since all other attributes are equal it falls the router-id to determine the best path. Setting R2 with a higher router-id and then clearing the BGP process to reset BGP to use its new router-id the issue should now be resolved.


R2(config)#bgp router 100
R2(config-router)#bgp router-id 2.2.2.2




R3(config)#router bgp 100
R3(config-router)#bgp router-id 3.3.3.3


R1#do clear ip bgp *


R1#sh ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 * i 192.1.1.1/32     192.168.13.3             0    100      0 i
 *>i                  192.168.21.2             0    100      0 i


 Sources


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

Lab 16 - BGP Best path selection - AS-Path Ignore

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


In this lab we will look at how to use a hidden command to modify the best path algorithms order of preference in order to change the pathing decision for a given BGP speaker. In this example we will stop BGP from using the AS_Path attribute when evaluating the best path to a given prefix.


Tasks:
-BGP peering has been configured for you
-loopback network have been configured for you.
-Modifying the BGP configuration on R1 only, ensure traffic from AS 10 prefers
the path to R2 for traffic destined for networks originating in AS 30
-Do not modify any configuration on R2, R3, or R4 to accomplish this
-Do not modify the weight or local-preference attributes on R1 to accomplish this
-Do not use redistribution or route-maps to accomplish this


Topology







GNS3 files: Link


Solution


As the lab states the peering configuration has already been configured for us which makes our work much easier. The lab asks us to modify the path decision made by R1 by only modify R1's configuration. We cannot change the other routers configuration. We also cannot modify the weight or local preference attributes or use static routes or a route-map. Well the limits our options quite a bit.


So let's look first at how R1 RIB table looks.


R1#s ip bgp
BGP table version is 5, local router ID is 1.1.1.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.1.1.0/24       0.0.0.0                                     0                         32768    i
 *>  4.4.4.0/24       192.168.13.3                                                              0    20 30 ?
 *                              192.168.12.2                   1000                                  0    20 30 30 i




It's important to understand what the various flags mean when looking at the show ip BGP command. This provides a wealth of information and for us tells us how BGP decided on the best path.


A couple of things stand our here. First the path to R2 has a metric of 1000. According to the best path selection order of preference the lower metric is preferred.  Also, the origin for R3 is incomplete which is the least preferred compared to IGP for R2. Third the path for R2 is shorter, less autonomous systems listed, then R2. So the order of preference to evaluate equal cost paths is AS_PATH, then Origin, then MED. Given the AS_PATH for R3 is shortest its selected as the best path.


But the labs asks us to make R2 the preferred path but without modifying any attributes. This might seem a challenging task but for this example its actually quite straight forward.


There is a hidden locally significant command that can be enabled which will tell BGP not to include the AS_PATH attribute in its best path algorithm. If you look closely at the show ip bgp output you will see that if AS_PATH is not compared the next attribute to be evaluated is the origin and as it turns out IGP is preferred over incomplete. So by simply adding the hidden command bgp bestpath as-path ignore and then clearing the bgp process which should see R2 become the new best path


R1(config)#router bgp 10
R1(config-router)#bgp bestpath as-path ignore


R1#clear ip bgp * soft


R1#sh ip bgp
BGP table version is 7, local router ID is 1.1.1.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.1.1.0/24       0.0.0.0                          0                  32768  i
 *   4.4.4.0/24       192.168.13.3                                             0  20 30 ?
 *>                          192.168.12.2          1000                          0  20 30 30 i


Now we have achieved our objective, the path through R2 is now the preferred path due to the origin of IGP being preferred over incomplete from R3. Also, keep in mind this is not a command that you would normally configure in a production environment unless you fully understood the implications and impact. The only time that it might be necessary to use this command is when evaluating eBGP routes that have the AS_CONFED attribute.


Sources


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


http://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp1.html#wp1112361

Lab 15 - BGP best path selection - Always compare MED

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


Enabling the always-compare-med option in BGP ensures the comparison of the MED attribute for paths from peers in different autonomous systems. In our lab today we have an enterprise (R1) that peers with two different ISP's which is receiving identical length paths to a third autonomous systems (R4) prefixes. Our job is to make the path to 4.4.4.0/24 go through R3 using only the MED attribute.


Tasks:
-BGP peering has been configured for you
-loopback network have been configured for you.
-Modifying the BGP MED attribute and related configuration only, ensure traffic from AS 10 prefers
 the path to R3 for traffic destined for networks originating in AS 40
-Do not modify any configuration on R4 to accomplish this
-Do not use redistribution or route-maps to accomplish this
-Do not modify any other path attributes other than MED to accomplish this


Topology







GNS3 files: Link


Solution


In our lab peering has already been established so we just need to focus on understanding the problem and resolving it. Let's begin by looking at the path selection on R1.


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   30 40 i
 *>                           192.168.12.2                                            0   20 40 i


So currently R1 prefers the path through R2 for the 4.4.4.0/24 prefix. All things being equal the best path algorithm is choosing the path with the lowest router ID because all the higher priority attributes are equal, i.e. weight, local preference, as_path, origin, etc.


So the solution should be easy, we just modify the MED attribute so that R3 is prefered and we should be all set.


R2(config)#route-map SET_METRIC permit 10
R2(config-route-map)#set metric 1000


R2(config-router)#neighbor 192.168.12.1 route-map SET_METRIC out


So with our MED configured on R2 which should be R2 less preferred we should our path change once we clear the BGP process to speed things along.


R2#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   30 40 i
 *>                            192.168.12.2                                                 0   20 40 i


Wait nothing changed, our preferred path is still through R2, what happened. We by default the MED attribute is only evaluated from peers in the same autonomous system. Because R2 and R3 are in different AS's the MED values are ignored and the next tie breaker is the router ID. Now our lab tell us we must solve this problem using the MED attribute so we need to tell R1 to look at the MED value. This is where the bgp always-compare-med command comes in. It tells the local BGP process to evaluate the MED value even if those values are from different autonomous systems. Let's apply this command now and see what happens.


R1(config)#router bgp 10
R1(config-router)#bgp always-compare-med


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   30 40 i
 *                               192.168.12.2         1000                              0   20 40 i


There we go, now that looks much better.


Sources


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

Lab 14 - BGP Best path selection - MED

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


In this lab we will look at the BGP MED attribute and how to use it for traffic engineering purposes. The MED attribute is an optional non-transitive attribute. It is essentially a hint to a neighbor about the preferred path into an autonomous system.


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 entering from AS 10 that originates in AS 30 enters AS 20
via R2 using the MED attribute only to accomplish this.




Topology







GNS3 Files: Link


Solution


Let's being by complete our initial tasks of establishing our peering.


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


With that in place and confirmed by using the show ip bgp summary command, it's important to confirm what you have configured is working, we advertise our loopback addresses as requested in the lab.


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


The next task requires that we control how AS 30 traffic leaving AS 10 enters AS 20 by using just the MED attribute. This attribute is only evaluated if all other higher priority attributes are of equal value, see the list above for those attributes. Since no specific criteria was given to how we accomplish setting the MED the easiest method is to just use the set command in a route-map and apply this outbound to the neighbor statement for the path we do not want traffic going over because the lower MED is preferred. So we want to set the MED higher to make the alternative paths more preferred.


R3(config)#route-map SET_MED permit
R3(config-route-map)#set metric 1000
R3(config-route-map)#exit


R3(config-router)#neighbor 192.168.13.1 route-map SET_MED out


R1(config-router)#do 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.12.2                           0 20 30 i
 *>                   192.168.13.3                           0 20 30 i


R1#clear ip bgp * soft
<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.12.2                           0 20 30 i
 *                    192.168.13.3          1000             0 20 30 i


R1#traceroute 4.4.4.4 source 1.1.1.1
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.12.2 36 msec 36 msec 60 msec
  2 192.168.24.4 60 msec *  72 msec


Pretty straight forward…and we are done.


The GNS3 files include the base configuration as well as the final solution discussed here.


Sources:


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