BSCI - Authentication in EIGRP, OSPF, IS-IS, BGP

Like my previous post, the way authentication is applied for each protocol varies in a EIGRP, OSPF, IS-IS, and BGP.

EIGRP:
Supports MD5/Plain text
Applied to the interface that connects to the neighbour, must be the same at each side.

Configure by doing:
R1(config)#int s0/0
R1(config0if)#ip authentication eigrp 1 md5
R1(config-if)#ip authentication key-chain eigrp 1 EIGRP_AUTH
!
R1(config)#key-chain EIGRP_AUTH
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string P@ssw0rd
!

OSPF:
Applied on the interface
Can be MD5/Plain text
Configure the same authentication on all neighbors

Configure plain text:
R1(config)#int s0/0
R1(config-if)#ip ospf authentication*
R1(config-if)#ip ospf authentication-key 1 P@ssw0rd
  *This cmd, without any switches, configures authentication in plain text

Configure MD5 authentication:
R1(config)#int s0/0

R1(config-if)#ip ospf authentication message-digest

R1(config-if)#ip ospf message-digest-key 1 md5 P@ssw0rd

!

IS-IS:

Offers 2 layers of authentication

i) Area-Passwords - between Level1 routers

ii)Domain-Password - between Level2 routers

Can be plain text or MD5 (out of scope of BSCI though)

Apply the cmd on all routers within the area or domain (for Level2)

Configure Level1 plain text authentication by:

R1(config)#router isis

R1(config-router)#area-password P@ssW0rd

!

Configure Level2 plain text authentication by:

R2(config)#router isis

R2(config-router)#domain-password P@ssw0rd

!

Protect specific links by applying the authentication on the interface:

R2(config)#int s0/0

R2(config-if)#isis password P@ssw0rd level-2*

 *you should state the router level to apply the authentication to, default is level1

BGP:

Uses MD5 authentication

Must be configured on each side of the neighbor relationship otherwise the connection is not made

Configure authentication by:

R4(config)#router bgp 100

R4(config-router)#neighbor 10.1.1.1 password P@ssw0rd

BSCI - Route Summarisation with RIPv2, EIGRP, OSPF, IS-IS, BGP

Something I seem to be struggling with is committing to memory how to implement route summarisation within each routing protocol. So in this post I'm going set down the necessary steps to implement summarisation in each protocol.


RIPv2:
On the router running RIPv2 you apply the summary to the outgoing interface:
R1(config)#int s0/0
R1(config-if)#ip summary-address rip 10.0.0.0 255.252.0.0


EIGRP:
Firstly disable auto summarisation-
R1(config)#router eigrp 1
R1(config-router)#no auto-summary


Next apply your summary route to the OUT Bound interface -
R1(config)#int s0/0/0
R1(config-if)#ip summary-address eigrp 1 172.16.0.0 255.255.224.0 


Points - Configured on a per interface basis, Router creates a NULL0 entry as loop prevention (longest match rule works here so if there isn't a more specific route within the summary route the router will drop the packet), When the last specific route within the summary is removed the NULL0 entry is removed.


OSPF:
Summarisation is performed on the ABR and ASBR only.
ABR - Applied to routes from within one area and summarised in to another area
ASBR - External routes are redistributed INTO ospf from protocols such as RIPv2 or EIGRP


For Intra-area route summarisation, on the ABR do:
R1(config)#router ospf 1
R1(config-router)# area 1 range 192.168.64.0 255.255.224.0
  *Area number is the area you are summarising FROM
 *#sh ip route - will show a NULL0 route to help prevent routing loops
 * #sh ip ospf database - will show the summary route


For Inter-area route summarisation, on the ASBR do:
R4(config)#router ospf 1
R4(config-router)#summary address 192.168.64.0 255.255.224.0
 *Advertises a summary route for all routes within 192.168.64.0/19 subnet


Note - By default ABR's and ASBR's do not summarise routes.


IS-IS:
Summarisation to be done on a Level1/2 router, which injects level 1 routes in to level 2.
If summarisation is being implemented, ALL level1/2 routers in the area need to be configured for summarisation.
Otherwise if one router advertises a more specific route then the Level 2 router will direct all traffic to that one router (due to the Longest Match rule).


On the Level1/2 router do:
R5(config)#router isis
R5(config-router)#summary-address 192.168.0.0 255.255.0.0 level-2
 *You state which level router you are summarising in to (default is level-2).


BGP:
BGP will not advertise a summary route unless the route can be first located in the Routing Table. As a result you can't simply apply a summary in the BGP process as it won't exist in the RT and therefore will not be advertised.


To get round this you first add a static route for the summary point to NULL0 and then you apply your summary route in BGP.


To do this do:
R2(config)#ip route 192.168.0.0 255.255.0.0 NULL0
!
R2(config)#router bgp 100
R2(config-router)#network 192.168.0.0 mask 255.255.0.0

BSCI - OSPF - Area Types - Not-So-Stubby-Area (Dude!*)

(*sorry, can't help it - I just keep hearing some surf dude trying to think up a clever name to describe these area types and not succeeding very well...) 


Not-So-Stubby-Area (NSSA) - special area type for when you end up adding a way out of the network via a Stub Area. For example you take over another company and you want to extend their RIPv2 network in to yours by making a router that was in your stub area an ASBR.

ISP~~~~(ASBR1) ----AREA0----(RouterB)---Area1-NSSA---(RouterA)~~~~New RIPv 2 Network

• In the (crude) example above, RouterA was within the stub area attached to RouterB. It now has a path to external networks attached to it.
• To Address the fact that RouterA is in a stub area, this area is configured to be a NSSA and in turn RouterA directs Type7 LSA packets to the ABR, in this case RouterB.
• RouterB in turn takes this Type7 LSA and converts it in to a Type5, External Link, LSA and propagates into Area0.

Configure a NSSA

1) On all the routers in the NSSA do:

RouterA(config)#router ospf 1

RouterA(config-router)#no area 1 stub

   *remove the stub configuration

RouterA(config-router)#area 1 nssa

2) On the new ASBR within the NSSA redistribute your required RIPv2 netrworks:

RouterA(config)#router ospf 1

RouterA(config-router)#redistribute rip subnets

3) On the NSSA ABR, which is RouterB in the example above, do:

RouterB(config)#router ospf 1

RouterB(config-router)#area 1 nssa default-information originate

  *This causes RouterB to generate a O* N2 default route of 0.0.0.0/0 and propagate in to the NSSA

BSCI - OSPF - Area Types - Totally Stubby Area (Dude!)

Totally Stubby Area - Cisco Proprietary, reduces the Routing Table further.

• Blocks external Type5 LSA's, Summary Type3 LSA's, and ASBR Type4 LSA's
• Totally Stubby Area only recognises intra-area routes and the default route 0.0.0.0
• ABR's inject the default route in to the Totally Stubby Area
• Each area router picks the closest ABR as its DFG

Configure a Totally Stubby Area

1) Configure OSPF as usual

2) Define the area to be Totally Stubby, as a Stub on all routers in the area, using the cmd:

R4(config)#router ospf 1

R4(config-router)#area 4 stub

3) On the ABR configure Area 3 to be Totally Stubby:

R5(config)#router ospf 1

R5(config-router)#area 4 stub no-summary

On the ABR the Routing Table will not change.

On the Totally Stubby router the routing table should only see routes in it's area and a default route to the ABR.

BSCI - OSPF - Area Types - Stub Area

Stub Area - Does not accept Type5 LSA's (External routes)

• Type5 LSA's replaced by a default route from the ABR
• All routers within the Stub area must be configured as a Stub Router

Configure a Stub Router:

R1(config)# router ospf 1

R1(config-router)#area 2 stub

  *Note the adjacency will fail until the neighbor plus the ABR is configured as a Stub as well

NOTE - On the ABR #sh ip route - will not change

On the Stub router, #sh ip route - routes from the ABR are replaced by a default route.

BSCI - OSPF - LSA types

Link-state Advertisement Types are as follows:
 Type
 1 - Router LSA - Most common, used in an Area, lists a routers neighbor and it's cost
 2 - Network LSA - Generated by DR/BDR, advertises all routes with in an area - Does not cross the ABR
 3 - Summary LSA - ABR's generate these to summarise routes from a different area, sent between areas,    summarisation is manually configured.
4 - ASBR LSA - Sent FROM an ABR with the IP's of ASBR's in any OSPF areas. Routes in OSPF areas use these to locate the external network.
5 - External Link LSA - Advertises ASBR summary routes out, contains routes external to OSPF
7 - NSSA External LSA - Similar to Type5 LSA but generated by an ASBR in a Not-So-Stubby-Area, converted in to Type5 LSA's by the receiving ABR

BSCI - Study Pointers - IPv6

IPv6

• FF00::/8 = Multicast prefix for all multicast traffic
• Link-LSA's and Intra-area LSA's are not used in OSPFv2 (Included in OSPFv3)
• R2(config-if)#ipv6 ospf cost 50 - this cmd sets the cost of a packet on this interface
• R2(config)#ipv6 unicast-routing - required when configuring a router for IPv4/IPv6 Dual Stack
• In a tunnel the header will look like - | ipv4 header | ipv6 header | ipv6 data |
• In OSPFv3 Type3 and Type9 LSA's carry all IPv6 Prefix info
• Local-Link LSA's aree flooded through the OSPF area
• IPv6 autoconfiguration allows a device to connect to a network without further config or the use of a DHCP server
• Enable a IPv6-to-IPv4 tunnel using: 

          R3(config)#interface tunnel0
          R3(config-if)#tunnel mode ipv6ip
               *apply this on both ends of the tunnel

BSCI - Study Pointers - Multicast

Multicast:

Disadvantages of Multicast:

• Lack of congestion control results in increased network degradation as the volume of network traffic rises
• Best effort delivery - can lead to packet drops affecting VOIP/Video delivery
• Eavesdropping is a security issue due to the nature to the protocol

Further points:

• 224.0.1.1 = NTP protocol
• GLOP and Limited scope addresses are types of Multicast address
• RP-Announce msgs sent to 224.0.1.39
• RP-Discovery msgs  (group-to-RP mapping msgs) sent to 224.0.1.40

BSCI - Study Pointers - BGP

BGP:

• When configuring eBGP peers between peers that are not directly connected you use the - 'R2(config-router)#neighbor 192.168.10.1 ebgp-multihop [hops]' - cmd on both peers.
• On an iBGP router that is a border router configure- 'R2(config-router)#neighbor 172.16.30.1 next-hop-self' -  to advertise the next hop as it's self to the rest of the iBGP peers
• Send the default route information to a specific peer - 'R2(config-router)#neighbor 172.16.30.1 default-originate'
• 3 well know mandatory BGP attributes - AS_PATH, NEXT_HOP, Origin

BSCI - Study Pointers - Route Redistribution

Route Redistribution:

• EIGRP Summary route AD = 5
• Passive Interfaces - Updates are not sent or received through the interface
• The cmd R3(config-if)#ip help-address 10.2.2.2 - is applied in the inbound interface on the DFG for the host :
• i.e  HOST -------*(R3)>>>><<<<(R4)--------DHCP Server1
• *applied at this interface

• DHCP Allocation Mechanisms - Automatic, Dynamic, Manual

BSCI - Study Pointers - IS-IS

IS-IS:

• Level 3 routing - routing between separate routing domains
• All ES's and Level1 IS's must have a unique system ID area wide
• IS-IS is able to have more routers in an area compared to OSPF and fewer Link-State PDU's are used.
• In Frame-Relay, the highest local DLCI is used to elect a designated IS (if all priorities are the same)
• the cmd R1(config-if)#isis password [password] [level] -sets authentication for a specific link, when level is not specified the default is level 1
• an INIT state can exist is there is a mis-matched authentication config or mis-matched MTU.

BSCI - Study pointers - OSPF

With my exam fast approaching this post is a simple list of points that for some I'm struggling to commit to memory.

You'll probably cast your eye of these and think 'what's the problem?' or 'D'uh!' but you're not me. And it's only easy if you know the answers.

So here they are:
OSPF:

• When configuring a virtual link you specify the are to be traversed plus the Router I.D. of the end point.
•  e.g. - R1(config-router)#area 5 virtual link 3.3.3.3
•  Then on remote router: R3(config-router)#area 5 virtual-link 1.1.1.1

• When working on a Frame-relay environment you need to enter the network type cmd under the OSPF process:
• R2(config-router)#ip ospf network non-broadcast
• At the interface you need to set OSPF priority to prevent DR election on the routers that will not be a DR:
• R2(config-if)#ip ospf priority 0

• An INIT state can exist when a router ID has not been seen in a received Hello Packet
• A Stub area doesn't accept information from outside of the OSPF AS
• ABR's maintain a separate link-state database for each area they are attached to.

BSCI -IPv6 - 6to4 tunnel addresses

When you create a 6to4 tunnel you need to apply suitable IPv6 addresses to the tunnel interfaces.

To do this you can take your IPv4 IP address which will be the source IP and convert it to an IPv6 address.

1) Using a Global address you know 2 things A) the high order bits always start 001 = 2000::/3 and generally end with 0001 in the first 16bits and B) a Global prefix is 48 bits long ( or /48). With this in mind  you know your first 16 bits, 0010 0000 0000 0001: X:X:X:X:X:X:X, so you are looking for the remaining 32 bits to form the address

2) Copy out into binary the IPv4 address of the physical interface the tunnel will be be associated with then convert it to hex, e.g.) 192.168.99.1
    1100 0000. 1010 1000. 0110 0011. 0000 0001
      c     0        a      8       6     3      0     1

3) Combine this with your first 16 bits and you have your Global IPv6 to apply to your tunnel interface
     2001:c0a8:6301::/48

Practise doing this quickly, again I've not taken the exam, but just like subnetting and Multicast MAC addresses it strikes me as an obvious exam question and an easy mark to pick up quickly leaving you time to work on the harder questions.

BSCI - Multicast - Well known Multicast IP's

Here is a useful list of multicast IP's

224.0.0.1 - All multicast systems on the subnet
224.0.0.2 - All multicast Routers on the subnet
224.0.0.4 - All Distance Vector Multicast Routing Protocol routers
224.0.0.5 - All OSPF routers
224.0.0.6 - All OSPF DR/BDR routers
224.0.0.9 - All RIPv2 routers
224.0.0.10 - All EIGRP routers
224..0.0.13 - All PIMv2 routers
224.0.1.1 - NTP time servers
224.0.1.39 - for Auto-RP rp-announce
224.0.1.40 - for Auto-RP rp-discovery

BSCI - Multicast - 224.0.1.40, where did that come from??

When you are configuring PIM in Sparse-Dense mode every router automatically subscribes to the Rendezvous Point Discovery group 224.0.1.40 .

This why when you do #sh run you may have entries for:
!
ip igmp join-group  224.10.50.1
ip igmp join-group  224.10.70.1
!

But when you do  - #sh ip igmp groups
You acually get listed:
Group Address
224.10.50.1
224.10.70.1
224.0.1.40

Confusion cleared!

BSCI - Multicast - Work out IP Multicast MAC addresses

You can work out what the multicast MAC address is for a given multicast IP by using the following steps.

1) First stage is to remember that all multicast MAC addresses start 01-00-5e totalling 25bits (IANA allocated 24 bits plus an extra bit set to zero so this totals 25 bits). What remains is 23 bits to use for the MAC (48bits in total).

2) Take your multicast IP and right it out in binary e.g.
- 224.10.60.3 = 1110 0000. 0 | 000 1010.0011 1100.0000 0011
                                                 23-bits to convert to a MAC

3) Now convert each group of 4 bits to Hex working from right to left
1110 0000. 0 | 000 1010.0011 1100.0000 0011
-                     0     a     3      c     0      3

4) Combine the converted Hex with the fixed multicast MAC bits:
- 01-00-5e-0a-3c-03

There you go. Relatively easy. Just remember that due to the 24 bits plus the zero bits that its best to work from right to left and you shouldn't go wrong.

I don't know, since I've not taken the exam yet, but to me this has exam question written all over it. Practice this so you can create multicast MAC addresses from a given multicast IP and you should have a mark in the bag.

BSCI - Multicast - #sh ip mroute

To determine the state of multicast on your router use #sh ip mroute

Options are as follows:
summary - One liner for each entry int the IP Multicast routing table
count - View stats regarding group and source, packets, and bits per second
active - Displays rates that active sources are sending to multicast groups

BSCI - Multicast - Notes

This article is more of a reminder to me on some of the finer points of multicast show commands.

1) #sh ip mroute - in the output of this cmd the neighbor stated in the RPF field is the upstream router to the multicast source

2) #sh ip mroute summary - displays active multicast groups
 
3) #sh ip pim interface count - The H parameter identifies the IP-Multicast, MLS-enabled interfaces

4) #sh ip pim int s0/0 - displays the IP of the next hop router, number of PIM neighbors discovered, PIM mode

5) IGMPv3, receivers signal membership to a multicast host group in either Exclude or Include mode

BSCI - eBGP multi-hop behaviour

EBGP peers are generally connected via their physical addresses. This is because there wouldn't be any internal routing (eigrp, ospf etc) between the 2 AS's and so the router wouldn't know how to connect to a loopback address located in a different AS.

But what if for resilience purposes you want 2 eBGP peers to establish a neighbor state via their loopback addresses, or for that matter you want to peer with an eBGP that is more than one router away? eBGP peers are usually one hop away. The 'ebgp-multihop' command allows you to extend the number hops an eBGP packet can pass through before the TTL expires. The default TTL is 1 and 1 hop gets you to the physical interface on your eBGP peer, no further.

Take this 2 router example, connecting to loopback interfaces:
  AS100 - lo0 =10.1.1.1/32------(R1)>>>><<<<(R2)--------lo0 = 10.20.20.2/32 - AS200

The first step is to apply a static route on your routers so the router knows where to send traffic for the eBGP peer's loopback address.

R1(config)#ip route 10.20.20.2 255.255.255.255 int s0/0
!
R2(config)#ip route 10.1.1.1 255.255.255.255 int s0/0

Next, you go in to the BGP process and enter the your configuration for the eBGP peer:
R1(config)#router bgp 100
R1(config-router)#neighbor 10.20.20.2 remote-as 200
R1(config-router)#neighbor 10.20.20.2 update-source lo0
R1(config-router)#neighbor 10.20.20.2 ebgp-multihop 5
!
Do likewise on the remote peer:
R2(config)#router bgp 200
R2(config-router)#neighbor 10.1.1.1. remote-as 100
R2(config-router)#neighbor 10.1.1.1 update-source lo0
R2(config-router)#neighbor 10.1.1.1 ebgp-multihop 5
!

In this example you are increasing the TTL to 5 allowing the packet to traverse 5 hops before the packet is dropped. This will in turn allow you get to your peer's loopback address and establish a neighbor state.

For eBGP peers that are more than one router away you still need to apply the 'ebgp-multihop' command on the 2 peer routers but you also need to make sure you have routes for the loopback interfaces of the eBGP peers on the intermedaite routers, otherwise you will end up with a 'black hole' and packets being dropped as there is no vaild route to the peers.

BSCI - Advertise a summary route in to BGP

Before BGP advertises a route it must be able to find it in the routing table.

This presents a problem when it comes to advertising a summary route as the summary you wish advertise will not be acutally listed in the routing table. Your subnets will be but the summary route wouldn't be.

To get round this you first configure a static route for your summary route which in turn is added to the routing table:

R1(config)#ip route 192.168.0.0 255.255.0.0 NULL0

This adds a static route pointing to NULL0 in to your routing table. Remember you will have more specific routes to the subnets you are wanting to summarise, such as 192.168.10.0/24, 192.168.20.0/24 and so on. As the routing look up works on 'Longest Match' this NULL0 static route is ok as you will/should always match the subnet with in the summary static route you applied.

With the summary route now installed in the routing table you can go ahead and advertise the summary in to BGP:
R1(config)#router bgp 500
R1(config-router)#network 192.168.0.0 mask 255.255.0.0
!

Here, you are advertising the class C /24 subnets as a /16 summary route. As there is a route in the routing table for this entry BGP will advertise it.

BSCI - Configure Local Preference

Local Prefence is used by iBGP peers to determine the Best Path out of the AS for a given route.

Set to 100 by default, the highest Local Preference wins.

You can either set the Local Preference on given router or for a specific route.

For a router do:
R1(config)#router bgp 100
R1(config-router)#bgp default local-preference [value]
        where [value] = a figure from 0 - 4294967295

All routes that R1 receives from an eBGP will have the local preference set to [value] when advertised to iBGP neighbors.

To set the local preference for a given route you use an ACL, define a  route map matching the ACL and then setting the Local Preference, fianlly apply the route-map to the necessary neighbor statements:
R2(config)#access-list 44 permit 10.10.10.0 0.0.0.255
!
R2(config)#route-map Local_Pref permit 10
R2(config-route-map)#match ip address 44
R2(config-route-map)#set Local_Preference 300
!
R2(config)#route-map Local_Pref permit 20
!
R2(config)#router bgp 200
R2(config-router)#neighbor 192.168.200.1 remote-map Local_Pref in
!

In the example above, route-map Local_Pref is configure to match networks permitted in ACL 44.

The route-map sets the Local Preference to 300 for the 10.10.10.0/24 networks. The second statement (permit 20) catches all other networks not covered in the (Permit 10) statement and as there are no match/set parameters these routes are processed as usual.

The route map is assigned to Neighbor 192.168.200.1 inbound. When R2 receives updates from 192.168.200.1 it assigns the local preference routes to 10.10.10.0/24.

Use #sh ip bgp to verify this.

If you have other routers with paths to 10.10.10.0/24 but you want to use R2 specifically for this route you define your route-map as above but set the Local Preference to one BELOW that of R2 - Remember HIGHEST LOCAL PREFERENCE WINS!

As a result when the route to 10.10.10.0/24 is advertised to other iBGP peers they select the path to R2 as the Best Path.

BSCI - Configure the MED or BGP Metric

The MED is used between eBGP neighbors and is the only means you have to try and influence how a remote AS views your routes.

To influence how a remote AS selects the best path for your given network you define an ACL to permit the routes you wish to influence, next you confiigure a route-map which matches the ACL then set the Metric to your value (remember lowest wins) finally you apply the route-map to your neighbour statement under the BGP process.

e.g.)
R1(config)#access-list 10 permit 192.168.10.0 255.255.255.0
!
R1(config)#route-map MED_OUTBOUND permit 10
R1(config-route-map)#match ip address 10
R1(config-route-map)#set Metric 100
!
R1(config)#route-map MED_OUTBOUND permit 20
R1(config-route-map)#set Metric 200
!
R1(config)#router bgp 500
R1(config-router)#neighbor 10.1.1.1 route-map MED_OUTBOUND out*

* route-map applies outbound to the routes you are advertising in BGP that match the ACL you configured.

In the example above routes for 192.168.10.0 advertised to BGP neighbor 10.1.1.1 will have a MED or Metric of 100. The default for MED is '0'

The next line (permit 20) states that 'All other routes' will have a Metric of 200. Remember Lowest Metric wins so by setting 'All other routes' to have a MED of 200 you are trying to influence the remote AS to use an different router (say R2) for 'All other routes'.

To ensure you influence the remote AS to direct traffic for 192.168.10.0 to R1 set the MED for 192.168.10.0 on R2 (plus any other routers that have a vaild path to 192.168.10.0) to a figure greater than that set on R1. Also for 'All other routes' set the MED to below that of the R1 catch all statement.

Keep in mind that MED or Metric is meets criteria 6 in the list of match statements for BGP path selection. If your route matches any of the preceeding criterion for Best Path selection then MED will not influence how the remote AS views the route you are advertising.

BSCI - BGP Path Selection Criteria

The following is a list of criteria that BGP uses in order to select 'Best Path'.

Remember that BGP does not perform load balancing. It selects which path is best and then enters that in to the routing table (assuming there isn't an IGP with a better Administrative Distance that has the same route).

The best path is firstly one that is free of loops (AS PATH does not have the same AS listed twice - if it does it must be a loop and the path is discarded). Next there must be a valid next hop, i.e. the router must be able to reach the next hop device. As such there will be a route in the routing table be it connected, a static, dynamically applied via an IGP. Once these 2 points are met then the following factors influence path selection. First match wins and the process stops.

1) Prefer Highest Weight - Cisco proprietary, locally significant, if another router receives the weight flag it is simply ignored.
2) Prefer Highest Local Preference - influences routes in bound to the AS. Use a route-map to set the Local preference (highest wins) then apply it to the nei statement for the routes you which to influence.
3) Prefer routes originated by the local router - these are the routes listed with 0.0.0.0 in the Origin field in #sh ip bgp summary
4) Prefer Shortest AS_Path - least number of hops wins, just like a distance vector routing protocol
5) Prefer lowest Origin Code - where the route originated from be it an IGP > EGP > ? or incomplete which usually indicates the route was received via reoute redistribution from another protocol such as EIGRP.
6) Prefer the Lowest MED - this is effectively the BGP metric and influences how remote AS's view the path of the routes you advertise.

There are many more factors that affect Best Path selection but the BSCI only requires you to know up to point 6 (and I can't be bothered listing the rest as it goes on some what, I think 'Router with tidiest cables in the back of the rack' is the last factor at number 17!? ;o) ) *

*not really