admin distance in BGP

[daniel ng]

in ios xe and xr, the 'distance bgp <external> <internal> <local>' command requires three numbers.

what is the purpose of <local>?Routing, Routing Protocols

[Martin L · Accepted solution]

• Third value (default 200): Local Distance. Click the number and enter the administrative distance for local BGP routes. Local routes are for those networks listed with a network command in the BGP routing process, that is, the networks that the process is advertising, or for the networks that are being redistributed to BGP from another process.

By default, Internal and Local values are the same 200; only external routes/value is 20

see Configure BGP General Settings link 

Regards, ML
**Have fun labbing!!!***
***Please Rate All Helpful Responses ***

[balaji.bandi]

Identifies Locally Originated Routes It applies specifically to routes that are part of the local Autonomous System (AS) and originated on that specific router.

Local-  Distance for routes generated locally by the router. Default: 200

Adjusting the local distance is typically necessary during route redistribution or migration scenarios. If a router learns the same prefix from BGP (locally originated) and another routing protocol (like OSPF or EIGRP), the router uses the AD to decide which one to install in the Routing Information Base (RIB). Lowering the local BGP distance below an IGP's distance (e.g., below 110 for OSPF) ensures the router prefers its own BGP-generated route over the IGP route. Sometimes you can change the local AD to prevent loops.

[Cristian Matei]

Hi,

   Although there are so many documents and training using / changing AD value during route redistribution, with the so called idea of preventing routing loops or suboptimal routing, this is just a lab learning exercise to let's say see the options and get a better understanding of the functionality. That's it, no more. Using / changing AD value to fix layer 3 loops, is a path to disaster, either the loop doesn't get fixed, either it just temporarily gets fixed until a race condition shows up. Why? The routing lop was one by your network design and routing protocol configuration, not by the RIB. So can one reason that to break the loop we need to change RIB attributes / aka AD value, since the RIB is not responsible for the loop to begin with?

  Not trying to be rude or harsh here, just ensuring we don't keep on propagating the same misinformation which has been done for years now. 

Thanks,

Cristian.

[balaji.bandi]

Not trying to be rude or harsh here, just ensuring we don't keep on propagating the same misinformation which has been done for years now. 

Not necessary here, since every one thinking and approach is different, my views may be different than yours, so that is reason this is community, we are not inventing anything new (are you ?) we are using what was written in the RFC, some may think different (i may be right my view point of view) rather your case may be different, it does not mean end goal changes (its different way to solve)

I have added my comments based on the documentation I used while learning.

I am happy the way you comment for OP post (its your views) and welcome all the time for right approach.

Things change quickly here, so a different view solves different problems. We only talk about what the RFC is based on; the real-world outcome may be different for the use case. (not necessarily always correct). 

[Cristian Matei]

Hi,

   While I agree there's different ways you can chew a gum, in this specific area I have to strongly disagree.

   There's no RFC stating Administrative Distances, as well as the internal workings of it, that we can relate to. AD started as a vendor specific thing many decades ago, and it was afterwards mostly copied by every other vendor, to keep inter-vendor compatibility, thus easier product adoption.

   The idea of AD being used as a methodology to prevent loops, started as a lab only exercise, decades ago, ultimately it was used to convey what can be achieved and why it should not be used to break loops as it can't, and when it will it's just temporary fix, not permanent. Afterwards, the details were lost and thousands of documentations and trainings showed up giving such examples, overlooking to state it should not be used and why not. And here we are today.

    I stay behind my statements and willing to both theoretically and practically demonstrate why it's not a permanent fix, thus useless to be used. 

Thanks,

Cristian.

[paul driver]

Hello @Cristian Matei 

---

@Cristian Matei wrote:

I stay behind my statements and willing to both theoretically and practically demonstrate why it's not a permanent fix, thus useless to be used. 

---

But would you agree it can be useful for certain instances - say protocol integration/migration?

[Cristian Matei]

Hi,

@paul driver My message regarding AD change to never be used, was towards using this mechanism to prevent / break loops. For routing protocol migrations / integrations, changing the AD value is a perfectly valid solution (the only one in order to have a smooth migration and have a fast and working fallback available), with the comment that at the end for the migration, highly recommended to revert back to the default AD of the protocol.

Thanks,

Cristian.

[Cristian Matei · Accepted solution]

Hi,

   The local admin distance configurable setting within BGP is one in along list of misunderstood topics, mostly because documentation and available training repeats over and over the same I would dare to argue, wrong idea.

    To understand and reason, I would first like state that clarify something additional. Although we configure Administrative Distance settings at the routing protocol level, the Administrative Distance is not a routing protocol attribute, it is a more of a RIB attribute. We all know that the RIB decides if for any given prefix / prefix-length tuple, RIB decides if it's gonna install the OSPF path or EIGRP path by comparing protocol Administrative Distances, so how can the AD be a routing protocol attribute; the routing protocol doesn't care about the AD value, the RIB does. The routing protocol is only responsible to decide what the best paths is, from a given set of valid paths, and sen that path to the RIB, with all associated attributes which are routing protocol specific, but the routing protocol does not attach the AD value when it sends the path to the RIB.

    Back to BGP Local AD, documentation states this is for locally originated prefixes (false and true at  the same time), example is given for locally injected prefixes via network statements or redistribution into BGP (false statement). BGP locally injected prefixes into BGP table are taken from RIB, so from RIB perspective the AD of those prefixes is the AD of the routing protocol that owns the entries, while once those prefixes show up in BGP RIB there's no AD value. So, then, what is the purpose of the BGP Local AD? It is BGP prefixes / best-paths sent by BGP to the RIB and installed in the RIB, as long as these prefixes / best-paths are not learned via EBGP or IGBP. So which prefixes match this criteria? Very few, one example is the outcome of a BGP summary / aggregate, because this is a BGP prefix / best-path, that BGP injects (it doesn't take it from the RIB), and when / if RIB installs it, it will use the BGP Local AD value for it.

     Take a IOS-XE router or layer 3 switch, have the following simple configuration:

interface GigabitEthernet0/0
 no shutdown
 ip address 10.10.10.1 255.255.255.0
!
interface GigabitEthernet0/1
 no shutdown
 ip address 10.10.20.1 255.255.255.0
!
router bgp 100
 network 10.10.10.0 mask 255.255.255.0
 network 10.10.20.0 mask 255.255.255.0
 aggregate-address 10.10.0.0 255.255.0.0
 distance bgp 20 200 210

Wait up to 60 seconds, the default BGP aggregate timer, and run following command to see the 10.10.0.0/16 present in BGP RIB:

show bgp ipv4 unicast 10.10.0.0

 Afterwards run following command to see the 10.10.0.0/16 installed in RIB with the value of 210, the BGP Local AD value.

show ip route 10.10.0.0 

Thanks,

Cristian. 

[paul driver]

Hello
As stated this command can be used to modify the administrative distance of bgp learned routes for best path selection.
The default values:
External(ebgp =20)
Internel (iBGP = 200)
Local (locally injected= 200)

Note: locally injected routes originate from either using the network command/ aggregation under the bgp process or from redistribution of routes into bgp

[daniel ng]

very informative. it is always good to see some insightful ideas beyond reciting from books or documentation.

since RIB only shows learnt route and BGP RIB shows no AD, how else if possible can we check out the local AD more easily?

what is the implication of changing this local AD?

[Cristian Matei]

Hi,

   In IOS-XE, you see the default AD's or configured AD's using command show ip protocols ; another option would be using command show running-config | section router , however this will not show you the AD's if you're using the default AD's, which you should in general.

    As for implications on changing the BGP AD for local, so the influence the BGP aggregate AD value:

1. Making it 255, which results in the aggregate no longer being installed in the RIB, could result in traffic blackholing as there's no longer gonna be the NULL 0 route installed in the RIB via BGP, and if the router has another less specific route installed in the RIB that incoming traffic will now match on, the router will route traffic that way; at the same time maybe this is what you purposefully want, to advertise an aggregate via BGP, however not having the NULL 0 route installed in RIB so that incoming traffic will be routed via RIB IGP entries.

2. Making it less than the AD of your IGP domain that the router is running / attached to, could result in traffic blackholing as now the BGP aggregate with a NH or NULL 0 will be installed in the RIB, instead of the IGP entry (if there was a perfect match on prefix / prefix-length advertised by the IGP); at the same time maybe this is what you purposefully want by having the NULL 0 route installed in RIB so that incoming traffic will be dropped / discarded.

3. Making it any other value than the above mentioned use-cases, in general it's just to lab / test / practice, see that the AD value changes, not aware of any real-life use-case for it.

Thanks,

Cristian.