BGP Bestpath igp-metric Ignore Required for Path Diversity?

[RGill94]

In reading the design guide for bgp path diversity with a shadow RR it highlights the need to configure bgp bestpath igp-metric ignore on all RRs if they are not "collocated."

My question is, if the shadow RR is receiving an advertisement that is considered second best (either by ibgp neighbor path selection rules or IBGP neighbor setting bgp advertise-best-external) why does the "bestpath metric ignore" matter if the shadow RR is set to advertise the backup path anyways via neighbor x.x.x.x advertise diverse-path backup.

In labbing this I did not set bgp bestpath igp-metric on either RR and the primary RR advertised the received bestpath just fine while the shadow RR advertised the second best just fine as well.

I think I may be misunderstanding the use case of collocated

Want to make sure I fully understand the need for bgp bestpath igp-metric as outlined in https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg_diverse_path.pdf

[pigallo]

Hello, The meaning of the term "colocated" should be taken, in this case, as belonging to the same IGP administrative domain. If so, when the RR (shadow) advertise path diversity to the remote BGP speaker, there is higher probability that IGP metrics will be equal in order to allow the PE to implement internal BGP multipath towards the destination (since there will be another path to the same destination via another next hop). If shadow RR resides into a different IGP domain, the advertised IGP metrics will be different than those of the primary RR. This is a BGP prerequisite for remote PE in order to enable multipathing with or without path diversity feature. If IGP metrics are different, even though you enable diversity, the best path selection occurs before the diverse path could be even taken into account for multipath computation because the speaker will choose always the NLRI with the lowest IGP metric. If you ignore igp metrics, you are forcing the BGP path selection process to skip igp metrics check, however this step is not related to path diversity. As the document says:" Disabling the Interior Gateway Protocol (IGP) metric check and configuring the BGP Diverse Path feature are independent of each other."

[RGill94]

Now disabling the IGP metric check on the PE receiving the advertisements in order to allow multipath makes sense. The guide points out that IGP metric ignore needs to be configured on both RRs. Why would IGP metric ignore need to be configured on the RR that is just reflecting routes and not forwarding traffic in the data plane?

[pigallo]

---

@gillrevie wrote:

Now disabling the IGP metric check on the PE receiving the advertisements in order to allow multipath makes sense. The guide points out that IGP metric ignore needs to be configured on both RRs. Why would IGP metric ignore need to be configured on the RR that is just reflecting routes and not forwarding traffic in the data plane?

---

The command can be implemented either on PEs and RRs.

The guide is correct. Before i just showed you a possible scenario.

Now think for a moment what you can achieve with this command. If your RRs are colocated and as guide says, they share the same subnet they have equal igp metrics to remote next hops.

What this implies from the perspective of the the two RRs ?

[RGill94]

So under the scenario where the RRs actually need the primary and alternate routes in their local routing table and the RRs are not collocated the igp metric would need to be ignored to overcome the bgp multipath requirement of same igp metric for both next hops.

Under the scenario where the primary and shadow RR are simply reflecting routes to a remote PE (neighbor advertise diverse-path backup on shadow toward PE) and not installing in their local routing table, igp metric ignore would only be necessary on the PE receiving the advertisements to allow for multipath in the RIB.

[pigallo]

---

Hi, see my answers inline:

@RGill94 wrote:

So under the scenario where the RRs actually need the primary and alternate routes in their local routing table and the RRs are not collocated the igp metric would need to be ignored to overcome the bgp multipath requirement of same igp metric for both next hops.

No, leave multi path away for a moment about RRs.

RRs are used just for control plane advertisement, as you correctly stated in your precedent post, so this means that you don't want place these devices in the forwarding path.

The fact that RR has the route in the rib is not relevant for our goal since that route won't be used.

Under the scenario where the primary and shadow RR are simply reflecting routes to a remote PE (neighbor advertise diverse-path backup on shadow toward PE) and not installing in their local routing table, igp metric ignore would only be necessary on the PE receiving the advertisements to allow for multipath in the RIB.

This is the example i suggested above but this can be applied to a PE not to an RR.

Additionally when the RR receives the NLRI, it will install anyway the bestpath in its rib, unless you don't activate particular features to prevent rib population.

---

There is an important point you are missing here that relates to BGP best-path selection process and to path diversity.

If you read again my previous question...."what implies the fact that RRs are colocated and share same subnet/IGP domain and equal metrics towards the remote destinations ? "

I'd like if you try to focus on my question, you can do it by your own.

[RGill94]

Bear with me, I'm not giving up on this one...

Answering your question, if the RRs are on the same subnet and collocated then they would have 2 equal cost paths in their bgp table. When the Shadow RR reflects the diverse-path route (second oldest route/same IGP metric for example) to remote PE, igp metric ignore is not needed anywhere, PE or RR.

In the case of different IGP metrics to next hops I'm still not seeing how IGP metric ignore would be needed on either RR if the primary only reflects the best bgp route (naturally)  and the Shadow only reflects the second best route it receives (Bgp additional-paths select backup & Neighbor x.x.x.x advertise diverse-path backup toward remote remote PE). Again, I can see the need for IGP metric ignore on PE not the RRs.

If the IGP metrics are different to both next hops why would it matter from the perspective of the Shadow RR if igp metric ignore is set if it is set to advertise/reflect the second best bgp route anyways - whether it be second best by higher local pref (for example) or higher IGP metric to next hop?

Ive gone over the guide extensively and I must still be missing something.

Thanks for the help

[pigallo · Accepted solution]

---

@RGill94 wrote:

Bear with me, I'm not giving up on this one...

Answering your question, if the RRs are on the same subnet and collocated then they would have 2 equal cost paths in their bgp table. When the Shadow RR reflects the diverse-path route (second oldest route/same IGP metric for example) to remote PE, igp metric ignore is not needed anywhere, PE or RR.

In the case of different IGP metrics to next hops I'm still not seeing how IGP metric ignore would be needed on either RR if the primary only reflects the best bgp route (naturally)  and the Shadow only reflects the second best route it receives (Bgp additional-paths select backup & Neighbor x.x.x.x advertise diverse-path backup toward remote remote PE). Again, I can see the need for IGP metric ignore on PE not the RRs.

If the IGP metrics are different to both next hops why would it matter from the perspective of the Shadow RR if igp metric ignore is set if it is set to advertise/reflect the second best bgp route anyways - whether it be second best by higher local pref (for example) or higher IGP metric to next hop?

Ive gone over the guide extensively and I must still be missing something.

Thanks for the help

---

Hi,

if two colocated RRs that share same igp metrics receive the same route via two different next hops they agree on what?

They both agree upon which path is the best path and which one is the backup.

They cannot disagree about it.

This is the main point you were missing. They belong to the same subnet and share equal metrics thus they both perceive the topology in the same way.

Now try to imagine if they belong to different IGPs and/or share different metrics what can happen if the RR(shadow) perceives, as best path, what is the backup path for the primary RR.

In this case the primary RR selects its best path and advertise it towards remote PE.

The shadow RR selects, as best NLRI, what is the backup path for the primary RR and if advertise diverse-path is in place you risk to install and advertise towards remote PE a path that it already has in its RIB. The PE will again calculate its best path against two equal routes and will end to install its best path into the rib.

What this means is that you loose diversity.

Unless you have a tool that allows you to make both RR view consistent across the AS and realign their perception of the best path.

This is where igp metric-ignore command applies.

Once you issue the command on both RRs, they will skip the igp metric tiebreaker and they will return to agree again about best path calculation based on lowest router-id. So this guarantee to you that the backup path advertised by shadow RR is the correct one because both RR agree on what is the best path to begin with.

Hope this helps

[RGill94]

Brilliant, that makes perfect sense.. I would think in that scenario you would forget diverse path completely and let each RR reflect its own best route to the PE. But you answered my question.

Thank you

[paul driver]

Hello

As it states, when "coloacted" (same ip subnet physical connected to a switch), The RR  will have the same igp metrics as such if the "Primary" RR fails there isnt a re-computation in igp for the shortest best path so the diverse path can be installed without disabling the igp metric check ( bgp bestpath igp-metric-ignore

However if the RR are not "coloacted" then re-computation in igp for the shortest best path will occur so in this case you will need to disable the igp metric check.

res

Paul