Hello Dan

Let’s take a look again at the entry of the 6.6.6.6 prefix on R1:

```
R1#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 5
Paths: (2 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
456
2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)
Origin IGP, aigp-metric 30, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 2
456
3.3.3.3 (metric 40) from 3.3.3.3 (3.3.3.3)
Origin IGP, aigp-metric 20, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
```

The path chosen was using R2, or 2.2.2.2 as the next hop. You can see from the above output that it gives an `aigp-metric`

of 30 whereas the alternate route via R3 gives an `aigp-metric`

of 20. However, these are just the metrics that R4 and R5 have advertised to R2 and R3 respectively. They are not the total metric to the destination.

How do we determine the total metric used to choose R2? Well, R1 takes a look at the advertised AIGP metrics, and adds the local IGP metrics for each path.

So for communication via R2, we have an advertised AIGP metric of 30, plus a metric of 20 to reach R2 (the value in parentheses in the above output), for a total metric of 50.

For communication via R3, we have an advertised AIGP metric of 20, plus a metric of 40 to reach R3 (again in the parentheses) for a total of 60.

So R1 chooses the path with the lower metric of 50. If we look at the output of the routing table for the 6.6.6.6 prefix what do we see?

```
R1#show ip route 6.6.6.6 | include metric
Known via "bgp 123", distance 200, metric 50
Route metric is 50, traffic share count is 1
```

A route with a metric of 50, which is what we got using the above procedure.

Similarly, for traffic from R6 to the destination of 1.1.1.1, using the same procedure we see we have a metric of 50 when routing traffic via R4 and a metric of 60 for traffic via R5, therefore tha path via R4 is chosen. Does that make sense?

I hope this has been helpful!

Laz