EIGRP Lab 1 - Multi-AF Mode

With the release of IOS 15 came several new enhancements and features one of which is EIGRP named mode. EIGRP has the advantage of consolidating all EIGRP commands into a single hierarchical set of configuration under router mode. Multiple address families and autonomous system can be configured under a single named instance of EIGRP. This lab will look at how to use named mode to configure basic EIGRP peering and prefix advertisement.

Tasks:

-Create loopback address on R1 using IP 1.1.1.1/24

-Create a loopback address on R2 using IP 2.2.2.2/24

-Create Named instances called EIGRP_R1 and EIGRP_R2 on R1 and R2 respectively

-Configure IPV4 address family to use autonomous system 10

-Establish neighborship between R1 and R2 using their directly connected links

-Advertise each routers loopback address

Topology

GNS3 files: Link

  

Solution:

We begin by creating our loopback addresses.

R1(config)#int loopback 0

R1(config-if)#ip address 1.1.1.1 255.255.255.0

R2(config)#int loopback 0

R2(config-if)#ip address 2.2.2.2 255.255.255.0

Next we create our named EIGRP instances on R1 and R1. The syntax is essentially the same to create the instance and get into router mode as with the classic mode. We type router eigrp then the instance name instead of the autonomous system number. Once in named router mode we move into address family mode using the command address-family ipv4 unicast [autonomous-system-number]. This is slightly different syntax compared to say BGP's address family syntax. From there we add our network statements to define which interfaces will participate in EIGRP.

R1(config)#router eigrp EIGRP_R1

R1(config-router)#address-family ipv4 unicast autonomous-system 10

R1(config-router-af)#network 145.1.0.0 0.0.255.255

R1(config-router-af)#network 1.1.1.0 0.0.0.255

R2(config)#router eigrp EIGRP_R2

R2(config-router)#address-family ipv4 unicast autonomous-system 10

R2(config-router-af)#network 145.1.0.0 0.0.255.255

R2(config-router-af)#network 2.2.2.0 0.0.0.255

With the configuration completed we need to verify that what we have done is working as expected. First lets confirm we have established peering between R1 and R2.

Next lets confirm we have our loopback networks in the global RIB table.

Everything looks good. I hope you enjoyed this brief lab on EIGRP named mode.

Sources:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-xe-3s-book/ire-classic-to-named.html

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