Uploaded byNetProtocol Xpert
BGP Loop Prevention
BGP uses the AS path attribute to prevent routing loops. When a route passes through multiple autonomous systems (AS), each AS prepends its AS number to the AS path. Routers will ignore any updates containing their own AS number in the path to avoid loops. This is demonstrated by enabling debugging on R2 - it rejects an update from R4 containing its own AS 65003 in the path. IBGP within an AS also prevents loops through the split horizon rule and a full mesh of IBGP sessions.
More Related Content
More from NetProtocol Xpert
BGP Loop Prevention
- 1.
- 2. • When BGPupdates 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.
- 4. • In Previousslide you can 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. • 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).
- 5. To see BGPloop 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 Black), there is an update sent by R4 to R2. That update was denied by R2 because it sees its own AS in AS-PATH.
- 6. • This ishow BGP handles BGP loop prevention of information updates between Autonomous Systems. • 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, 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.
- 7.