BGP loop prevention

Written on by admin on. Posted in BGP

When BGP updates travel through different Autonomous Systems (AS), EBGP routers prepend their AS to AS PATH attribute.  BGP routers use this information to check through which Autonomous Systems certain updates passed. If a EBGP speaking router detects its own AS in AS PATH attribute update, the router will ignore the update and will not advertise it further to IBGP neighbors, because it is a routing information loop. This is a built in mechanism for loop prevention in BGP.

Let’s consider the following scenario:

BGP loop prevention

In the scenario above you see four BGP speaking routers. R1 and R2 are in AS (Autonomous System)  65001 and form IBGP neighbor relationship with each other. R3 is in AS 65002 and form EBGP neighborship with R1 and R4. R4 is in AS 65003 and form EBGP neighborship with R2 and R3. The only network prefix advertised in BGP is 192.168.0.1, which is advertised by R1. All the other routers learn this route from BGP. Router R2 learns this network prefix directly from R1 which is in the same AS.  Also, this prefix is sent to R3 by R1 as a BGP routing update and by R3 to R4. Router R4 in turn will send BGP routing update to R2. And now, routing information loop would have occurred if loop prevention mechanism wouldn’t exist.   Because routing update about 192.168.0.0/24 received by R2 from R4 contains R2’s own AS (65001), R2 will reject that update and will not be sent further to other IBGP neighbors (in this case – R1).

To see BGP loop prevention in action, we’ll enable BGP debugging on R2 for updates received from R4, then will clear R4 (10.0.2.2) from BGP neighbors. See it in output  below:

R2#debug ip bgp 10.0.2.2 updates
BGP updates debugging is on for neighbor 10.0.2.2 for address family: IPv4 Unicast
R2#
R2#clear ip bgp 10.0.2.2
R2#
R2#
*Mar  1 00:12:27.455: %BGP-5-ADJCHANGE: neighbor 10.0.2.2 Down User reset
*Mar  1 00:12:28.679: %BGP-5-ADJCHANGE: neighbor 10.0.2.2 Up
*Mar  1 00:12:28.683: BGP(0): 10.0.2.2 send UPDATE (format) 192.168.0.0/24, next 10.0.2.1, metric 0, path Local
*Mar  1 00:13:00.219: BGP(0): 10.0.2.2 rcv UPDATE w/ attr: nexthop 10.0.2.2, origin i, originator 0.0.0.0, path 65003 65001, community , extended community
*Mar  1 00:13:00.223: BGP(0): 10.0.2.2 rcv UPDATE about 192.168.0.0/24 -- DENIED due to: AS-PATH contains our own AS;

As you can see (highlighted in red), there is an update sent by R4 to R2. That update was denied by R2 because it sees its own AS in AS-PATH.

This is how BGP handles BGP loop prevention of information updates between Autonomous Systems.  Well, that is just part of the story. To avoid routing information loops within the same AS, all IBGP routers must peer with every router within AS (only TCP sessions required, not physical connections) – this is called full mesh IBGP. IBGP uses split horizon rule (covered in other article), which states that routes learned from one IBGP neighbor is never sent to the rest of IBGP neighbors. That way, when you have full mesh IBGP, routing information loops will not occur, because all routers have the same routing information.

12696 views

Trackback from your site.

Comments (2)

  • Steve

    |

    Nice clearly written article.

    Reply

  • Amjad

    |

    Thanks for coming back after two years to write. eager to find more labs.

    Reply

Leave a comment


− 2 = one